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ABSTRACT 



During the last decade, the business sector has become increasingly reliant upon 
information management. This trend will most likely continue. Deficiencies/constraints in 
conventional database management systems continue to become more apparent as this 
reliance continues to grow. Primary areas of deficiency are in modeling, storing, and 
managing increasingly complex information as in CAD and CASE among others. 

The purpose of this thesis is to implement a combined relational/object-oriented 
database management system that will overcome these deficiencies/constraints. Three 
possible approaches to such a system exist: build the system from scratch, build object- 
oriented capabilities on top of an existing relational system, or build relational capabilities 
on top of an existing object-oriented system. The last approach is the one chosen for this 
work. This thesis expands previous work in this area and uses a commercial object-oriented 
database management system, IDB, in its implementation. 
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L INTRODUCTION 



A. MOTIVATION 

The popularity of Object-Oriented Programming (OOP) is steadily increasing. As 
more and more people develop an interest in the additional capabilities that arise from using 
the object-oriented paradigm, they realize the flexibility and power that OOP provides for 
representing real world objects in an intuitive and natural manner. This flexibility and high 
level of abstraction provided by OOP constmcts has lead many database professionals to 
consider object-oriented concepts as they relate to database management systems (DBMS). 

During the last decade, the business sector has become increasingly reliant upon 
information. Information management and control pays dividends to businesses in terms of 
increased power and revenue. In the coming decade, this reliance will surely increase. The 
requirement to manage very large quantities of data more efficiently and to perform queries 
on them rapidly is only part of the problem. The data that businesses wish to store and 
manage is becoming increasingly complex. 

Some specific areas that have an immediate need for a database to store and manage 
complex data are computer aided design (CAD), computer aided software engineering 
(CASE), computer-integrated manufacturing (CIM), and computer aided engineering. Data 
representing images and text is applicable to virtually all large businesses. In the medical 
field, for example, a patient’s medical file could be managed by a database that keeps track 
of not only the textual records from an appointment, but also x-rays, lab results, cat scan 
pictures, and other non-textual information. [Me90] 

The relational data model has existed for many years. It was developed by Codd in 
1970 [Co70]. This model quickly gained widespread acceptance and use commercially. 
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Much of the business sector has a heavy investment in relational databases, and the 
relational model is credible and familiar. Therefore, there is a reluctance to change to 
another model/system, even when there is a need. 

Vendors have realized the need for modeling complex information (visual, textual, 
audible, etc.). In response, several object-oriented databases management systems 
(OODBMS) are now available in the commercial market. Some businesses with a need for 
managing complex data are using them. Many of these businesses have expressed a desire 
for an interface that can access both object-oriented databases and relational databases 
[St91a]. 

B. OBJECTIVES OF A RELATIONAL/OBJECT-ORIENTED DATABASE 
SYSTEM 

In general, conventional database models are designed to meet the requirements of a 
specific need. As Hsiao states, “this is the notion of application specificity, i.e., being 
specific to a kind of database application.”[Hs91, p. 3] The general areas that the 
conventional data models, relational, hierarchical, network, and functional data models, are 
used for are record keeping, product assemblies, inventory controls, and inference making, 
respectively. [Hs9 1 ] 

The main objective of this research is to determine if a single DBMS can be realized 
that would serve the needs of both relational and object-oriented users. A relational DBMS 
(RDBMS) has many advantages over non-relational systems. There are, however, some 
constraints on relations, such as the type of real world entities that it can represent. 

An OODBMS has a more robust capability for representing real world entities as 
objects. The restriction on types of relations in a RDBMS can be lifted in an OODBMS. 
Both RDBMSs and OODBMSs have their own set of advantages, but they are not the same 
set of advantages. It is desirable to have a DBMS that has the advantages found in both of 
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these sets, plus any additional advantages that may arise from having a combined relational/ 
object-oriented database management system (R/OODBMS). 

The user of a R/OODBMS should be able to implement a relational schema and query 
the database using either ‘standard’ relational queries or an object-oriented type query. 
Thus, there would be a very low learning curve for users already accustomed to relational 
systems. Additionally, they would not have to abandon the relational approach that they are 
already familiar with for this new object-oriented paradigm. Yet, they would also gain the 
capability to manage complex data/objects with the same system. 

A secondary objective is to determine if any OODBMS can be the basis for a R/ 
OODBMS. That is, are there certain requirements that must be met by a commercial 
OODBMS so that a R/OODBMS can be successfully constructed? Also, are there any 
characteristics of these systems that would facilitate this construction more than others? 

C. RESEARCH OVERVIEW 

This is a feasibility study which continues previous work done in the area by Nelson 
[Ne88] and Filippi [Fi92]. Implementing relational operations in IDB is the primary thrust 
of this research. Additionally, assessing the capabilities and advantages of using both 
RDBMSs and OODBMSs falls within the scope of this research. A comparison of these 
assessments with that of a single R/OODBMS will follow so that it can be determined 
whether the needs of a RDBMS and an OODBMS can be satisfied by a single R/OODBMS. 
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II. SURVEY OF THE LITURATURE 



A. GENERAL 

The focus of this chapter is the fundamental terms and concepts in the areas of object- 
oriented programming (OOP), relational database management systems (RDBMS), and 
object-oriented database management systems (OODBMS). The discussion of these topics 
is not intended to be a complete work on them, but rather an introduction to present those 
concepts and terms necessary as a foundation for this thesis. 

B. OBJECT-ORIENTED PROGRAMMING CONCEPTS 

“I have a cat named Trash. In the current political climate, it would seem that if I were 
trying to sell him (at least to a Computer Scientist), I would not stress that he is gentle to 
humans and is self-sufficient, living mostly on field mice. Rather, I would argue that he is 
object-oriented” [Kin89, p. 23]. 

What does it mean for something to be object-oriented? Since the advent of Simula- 
67 in the 1960s and later Smalltalk in the 1970s [Mi88][Mo89], object-oriented 
programming languages (OOPLs) and the object-oriented paradigm have been increasingly 
great topics for discussion and debate. Different products are advertised as object-oriented, 
the hot buzzword, however there is no universally accepted definition 
[Kin89][Ne91][Ne90b][SB86]. 

“What is needed is a definition general enough to encompass all of the current views 
of OOP, yet strong enough to stand up as the basis for the underlying theory of OOP” 
[Ne91, p. 4]. The broad definition used in this paper is object-oriented = objects + classes 

+ inheritance + encapsulation. This is a slight modification of the definition in [We87].^ 
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Currently, there is also much debate about the design process for an OOP program. 
In conventional languages, several approaches have been formalized such as the top-down, 
bottom-up, structured, etc. These approaches are, in general, ‘action’ approaches while 
OOP uses an ‘object’ approach [GH91b]. However, the OOP community lacks any 
established methodology to their ‘object’ approach [PN91b]. This subject is considered to 
be beyond the scope of this paper, however, and as such will not be discussed any further. 

1. Classes/Objects 

A class may be defined as “a description of one or more similar objects” [SB86, 
p. 43]. An object is an instantiation of a class [Mo89]. Clearly, this is a circular definition 
which can be avoided by defining an object as the fundamental element of OOP. That is, 
an object is a self-contained set of variables (which may be thought of as attributes in 
database terms), and responds only to messages to execute specific defined procedures 
(also called methods in OOP terms) [BM91][Ne91][SB86]. An object’s method(s) are the 

2 

only means by which manipulation of its variables can occur. 

The description of an object/class is composed of variables/attributes and the 
procedures/methods that operate on them. These variables and methods describe general 
characteristics that all instances of a class have. The only way to communicate with an 
object is through messages to execute its methods. Thus, an object’s messages are the 
interface to a particular object. An important point is that the variables of an object may 



1. [We87] defines OOP as “object-oriented = objects + classes + inheritance”. It may be argued that 
this equation is the same as our slightly modified equation since some definitions of class imply en- 
capsulation. For a more detailed discussion, see [Ne91] 

2. Thus, a class may be thought of as an abstract data type (ADT) or as the implementation of an 
ADT [Da84][Ne91j. The interface to the data type is defined solely by the methods defined for the 
class. The implementation of these methods is contained within the class which allows the interface 
to be implementation-independent. 
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themselves be objects. In this case, the object is called a composite object that has at least 
one variable which is a previously defined object [EN89][Ne90b]. The composition of 
composite objects can be compared with inheritance where composition is a form of part 
inheritance the later is concerned more with behavior inheritance [Ne90b]. 

Most OOP languages provide for both class and instance variables, although it is 
not required for a language to be considered object-oriented [Ne91][Ne90b]. The 
difference is that a class variable will have the same value for all instances of the class. If 
a method in any of the instances of that class change the value of a class variable, then the 
value is changed for every instance of the class. Thus, it is a variable shared by all instances 
of the class. In contrast, an instance variable has a local value for a particular instance. A 
change to the value of an instances instance variable of one object has no effect on the 

corresponding variable in another instance of the class. 

Consider a military officer as an example of an entity that might be described in 
a class definition. The class name could be Officer with several variables that further 
characterize an officer. A possible class variable could be the number of company grade 
officers (0-1 through 0-3) that exist: CompanyGradeCount. Thus, every instance of the 
Officer class would have the same value for CompanyGradeCount. Each officer has a 
name, grade, social security number, and an assigned unit that may be represented by the 
instance variables Name, Grade, SSN, and Unit, respectively. These variables would be 
instance variables since each instance of an officer will not necessarily have the same 
values for each of these variables. This officer class definition is presented in Figure 1. 



3. IDB, the OODBMS used in this thesis, does not provide the capability to define class variables. 
However, in our discussions with Persistent Data Systems, they have mentioned that later versions 
of IDB may contain this capability. 
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Class: Officer 




Superclass: 


none 


Class Variables: 


CompanyGradeCount 


Instance Variables: 


Name, Grade, SSN, Unit 


Methods: 


Promote, Retire, Relocate 



Figure 1 Class Definition Example 



2. Methods 

As previously mentioned, methods are the means by which an objects variables 
are manipulated [Ne90b]. They define the only legal actions/operations that characterize an 
object. A method is invoked by sending an object a message to invoke one of its methods. 

A message can be likened to a procedure call in a conventional programming language.^ 
Changing the implementation details for any method should have no effect on messages 
needed to invoke that method [Ne90b]. Thus, code that uses message passing for method 
invocation is implementation independent. It is in this sense that the description/definition 
of class may imply encapsulation (also called information hiding). 

In our military officer example, it may be desirable to be able to promote, retire, 
or relocate an officer. Therefore, these three actions might be implemented as methods for 
the Officer class (see Figure 1). The Promote method would change the Grade instance 
variable and could change the CompanyGradeCount class variable; Relocate would change 



4. The exact implementation for the message passing concept may vary among different OOP lan- 
guages. Value operations (idl_vop) and type operations (idl_top) are the means by which IDB imple- 
ments message passing. 
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the Unit instance variable; and Retire would change the Unit and Grade instance variables, 
and possibly the CompanyGradeCount class variable. 

3. Inheritance 

Inheritance allows further specialization of a class (called the superclass) by 
exploiting class similarities [Ni89]. That is, a subclass inherits the variables and methods 

of its ancestors and adds its own variables and methods.^ In this way, it is a specialization 
of its ancestors and its ancestors are a generalization of the subclass 
[BM91][CY90][HO87][Hs91][Mi88][Mo89]. In more fundamental terms, it is a form of 
code sharing [Ne90b] that facilitates and encourages code reuse [Ni89][Mi88]. As you 

travel down an inheritance hierarchy^, classes become more specialized. As you travel up, 
they become more generalized. 

In Figure 2, the class Human is the superclass of the subclass ServiceMember. A 
simple inheritance hierarchy of these two classes is shown in Figure 3. Any ServiceMember 
will have Species as a class variable; Weight, Height, Sex, and Ssn as instance variables; 
and the methods Bom, Die, EnterService, and DepartService. A ServiceMember is a 
specialization of a Human, while a Human is a generalization of a ServiceMember. 



5. Inheritance of methods is sometimes called behavioral inheritance while inheritance of variables 
is called suuctural inheritance [Da90]. 

6. An inheritance hierarchy is simply a graphical representation of the inheritance relationship be- 
tween classes [Ne90bJ. 
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Class: 


Human 


Superclass: 


none 


Class Variables: 


Species 


Instance Variables: 


Weight, Height, Sex 


Methods: 


Born, Die 


Class: 


ServiceMember 


Superclass: 


Human 


Class Variables: 


none 


Instance Variables: 


Ssn 


Methods: 


EnterService, DepartService 



Figure 2 A Class and Its Subclass 



Human 

ServiceMember 

Figure 3 A Simple Inheritance Hierarchy 

Consider the inheritance hierarchy in Figure 4, Officer is now a subclass of 
ServiceMember. The ancestors of Officer are Human and ServiceMember, while its 
descendents are the subclasses CompanyGrade, FieldGrade, and FlagGrade. Thus, the class 
Officer inherits all the variables and methods from both Human and ServiceMember. 
Again, you can see that as you travel down the inheritance hierarchy the classes become 
more specialized while the classes higher in the hierarchy are more general. 



7. The Officer class definition in Figure 1 would have to be modified to reflect that ServiceMember 
is now its superclass. 
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Methods that are inherited by a class may have their implementation overridden 
(or redefined) while still maintaining the same method name [H087][Mi88]. This allows 
methods to be overloaded (also called polymorphism) [Ne90b][Ni89][SB86]. That is, the 
same message may be sent to different objects, invoking different implementations of the 
same method depending on the object which receives the message. A common example of 
polymorphism is that of the binary arithmetic operations on integers and real numbers. 
When we want to add two integers, we write 2+39; the same operator name ‘+’ is also used 
for the real numbers, 3.4+2. 1. 

In the example hierarchy (Figure 4), the subclasses of Officer all inherit the 
method Promote (along with the other methods of the Officer class). However, each of the 
subclasses (except for CompanyGrade) require a different implementation for the Promote 
method since promoting a FlagGrade or FieldGrade officer would not change the Officer 

class variable CompanyGradeCount.^ A method that has been overwritten by a subclass is 
a polymorphic method. 
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Up to this point, our discussion of inheritance has focused only on single 

inheritance: a class inherits from only one superclass.^ However, some languages allow for 
multiple inheritance: a class inherits from two or more superclasses [Ne91][Ne90b], The 
relationship between classes when multiple inheritance is allowed can be shown 

graphically in a multiple inheritance lattice^^ (see Figure 5) [SB86][Ne90b]. 




Inheritance is not without its own special problem which must be mentioned; that 
of name conflicts [Ki91][Mi88][Ne88][NMO90]. In Figure 5, assume that the Human class 



8. This assumes that in the Officer class definition the Promote method has the implementation pre- 
viously described: Promote changes the value of the CompanyGradeCount class variable. Thus, if 
the method’s implementation is not overwritten a message sent to any of Officer’s subclasses would 
invoke this implementation causing undesirable results. 

9. Generally, the term inheritance by itself means only single inheritance [Ne90b]. 

10. The term lattice by definition allows more than one superclass [SB86] while an inheritance hi- 
erarchy does not. This is in contrast to a hierarchy which is represented as a tree. However, it is fairly 
common practice to refer to a multiple inheritance lattice more simple as a multiple inheritance hi- 
erarchy [Ne90b]. 
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has a Print method that has been overridden in both the Officer and Student subclasses. 
Now, consider the class NpsStudent; which implementation of Print does it inherit? 

In the case of single inheritance, a subclass may inherit a method X or variable Y 
from its ancestors but also have a different method X or variable Y defined locally for the 
subclass [Ni89][NMO90]. That is, the subclass also has in its class definition a method X 
and a variable Y. How are the two different methods or variables differentiated? Usually 
locally defined methods and variables override any inherited methods and variables with 
the same name. However, some systems allow the overridden method/variable in the 
superclass to be accessed by prefacing the name with super; for example, superX or superY. 

Multiple inheritance has a similar name problem, however it is complicated since 
there is more than one superclass involved. It is not as simple to just preface a redefined 
name with super since more than one of the superclasses may have the same method/ 
variable name. In general, the possible solutions include making a choice between them 
using some default criteria [SB86] (such as a class precedence [Mo89][SB86]), by 
distinguishing among them [Ne88] (possibly by using their parent class name as a prefix 
[Ni89]), by combining them [Mo89][Ne88], or by requiring the programmer to make an 
explicit choice [Ki91][Mi88][Ni89]. 

4. Encapsulation 

“An OOPL supports encapsulation if it allows users of objects to access them only 
via their external interfaces” [Mi88, p. 15]. The external (public) interfaces to an object are 
its methods and these are the only means that a user has for accessing/manipulating an 
object. The user is not allowed direct access to the object and its inner workings[Da90]. 
Thus, encapsulation is a method of information hiding [Da90][Ne90b][Ne91] and offers 
protection to objects from unauthorized/illegal operations on its variables [Mo89j. 
Additionally, hiding implementation details provides a separation (or decoupling) from the 
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code that defines and implements an object from that of the program code using the object 
[Da90]. This point is quite important since it allows changes to an object’s implementation 
without having to change the user’s program code and vice-verse [Da90][Mo89][Ne91]. 

C. RELATIONAL DATABASE MANAGEMENT SYSTEMS 

Prior to discussing the relational model specifically, it is worth giving a few moments 
to the definition of a database management system (DBMS). A DBMS is a collection of 
general-purpose software programs that allow maintenance of and access to a collection of 
interrelated data [EN89][KS86]. A collection of interrelated data is called a database. 

However, when discussed in terms of specific DBMSs, the definition of database is a 
little more restrictive and has the following properties[EN89]: 

• the collection of data has some inherit meaning and is logically coherent; 

• the database is created for a specific purpose, an intended group of users, and 
some preconceived applications; and 

• the database models and reflects some real world aspect. 

The maintenance of and access to the data include facilities to define, create, and 
manipulate (i.e., query and update) it. 

There are numerous considerations for using a DBMS. Controlling redundancy: as the 
number of times the same data is stored increases, there is a corresponding increase in 
duplication of effort to update it; additionally, it is more likely that inconsistencies among 
the data may arise (update anomalies). Sharing of data: in a multiuser DBMS concurrency 
control of updates is critical to the correctness of updates. Restricting unauthorized access: 
the DBMS should allow restrictions to be placed on access to database data. Representing 
complex relationships among data: this includes easy and efficient retrieval and update of 
related data. Enforcing integrity constraints: database designers must be allowed to specify 
data constraints which the DBMS can enforce automatically or which can be enforced by 
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update programs. Provide backup and recovery: recovery from hardware and software 
failures is the DBMS’s responsibility. [EN89][KS86] 

1. Relational Model Concepts 

In 1968, Dr. Edgar F. Codd had the idea that “predicate logic could be applied to 
maintaining the logical integrity of the data” in a DBMS [CD90, p. 35]. This was the 
conception of the relational data model. Two years later, Codd introduced his model in a 
paper published in the Communications of the ACM [Co70]. It was a departure from what 
had until that time been the conventional models (hierarchical data model and the network 
data model) since his model allowed for a more abstract representation of the database 
[OV91][KS86][Fi92]. This simplistic yet complete model has evolved into a kind of 
defacto standard in the database industry. 

The relational model is firmly founded in strong mathematical concepts and 
theory. Predicate logic and set theory are the primary foundation upon which the relational 
model rests. This allows a formalism in the way that data is represented and manipulated 
in the context of the model. 

a. Relations 

The relational model represents a database as a collection of relations. 
Relations, the fundamental building block of the model, are represented by the intuitive 
notion of a table (or flat file) of values [Da84][EN89][KS86][OV91][SSU91]. Each row of 
the table represents a tuple of the relation. A tuple is a collection of data values that are 
related. The columns of the table represent attributes of the relation (see Figure 6). In the 
sample relational database, there are two relations: Officer and Military Unit. Each tuple is 
interpreted as a fact that describes a relation instance. Every attribute value within a tuple 

must be atomic. That is, it is not constructed of other components; it is indivisible.^^ 
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Officer 






Name 


SSN 


Unit 




Spear 


550-34-2453 


3BDE 


Walter 


233-45-3423 


2BDE 


Nash 


241-4500974 


IBDE 


Rothlisberger 


123-45-6789 


3BDE 


MilitaryUnit 






UnitName 


Location 


CtirSSN, 


IBDE 


Grafenwohr 


123-45-6789 


2BDE 


Erlangen 


550-34-2453 


3BDE 


Bamberg 


233-45-3423 



Figure 6 Sample Relational Database 



However, it must be understood that there is a subtle but important difference 
between a relation and a table. A relation is a set of tuples. On the other hand, tuples of a 
relation are represented as the rows of a table. A set by definition is unordered, but clearly 
the rows of a table are ordered (from top to bottom)[EN89]. Thus, the relation Officer in 
Figure 7 is the same as the Officer relation in Figure 6. 



11. This requirement for atomic attributes is called the first normal form. Normalization is a process 
of decomposing relational schemas into smaller relations that conform to several criteria: first, sec- 
ond, and third normal forms. The goal of normalization is to aid database designers in analyzing a 
database schema and developing a database with a ‘good’ design that avoids update anomalies. 
[EN89] 
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By the same token, the order of the columns is not important since a tuple can 
be thought of as a set of (<attribute>,<value>) pairs[EN89][Da84]. The value in each pair 
must fall within the domain of its associated attribute. Thus, the first tuple in Figure 7 could 
be written: (Name,Rothlisberger), (SSN, 123-45-6789), (Unit,3BDE); or (Unit,3BDE), 
(Name,Rothlisberger), (SSN, 123-45-6789); etc. 



Officer 



Name 


SSN 


Unit 


Rothlisberger 


123-45-6789 


3BDE 


Nash 


241-4500974 


IBDE 


Spear 


550-34-2453 


3BDE 


Walter 


233-45-3423 


2BDE 



Figure 7 Reordered Officer Relation 



The reason this subtle difference between relations and tables is important 
will become more apparent later. As will be discussed, all of the relational algebra operators 
take relations as parameters and yield results that are also relations [Da84]. Thus, they are 
set operations and they have firm foundations in mathematical set theory. Consequently, if 
someone has a good understanding of mathematical set theory, then they are well on their 
way to understanding relational algebra. 

Another consequence of a relation being defined as a set of tuples, is that, by 
definition, each element in a set is unique. Therefore, all tuples in a relation must be unique. 
This implies that there are no two tuples in a relation that have the same combination of 
values for all attributes [EN89]. Thus, there is some combination of attributes that allows 
each tuple of a relation to be uniquely identified; this combination is called a primary key 
(the primary key of each relation in Figure 6 and Figure 7 is underlined). In the worst case. 
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the primary key is the set of all attributes of the relation [Da84][EN89]. A detailed 
discussion of keys (including superkeys, minimal superkeys, candidate keys, primary keys, 
and foreign keys) can be found in [EN89]. 

b. Schemas and Constraints 

When discussing databases, it is important to differentiate between the 
database schema and database instance. A database schema is a set of relation schemas and 
a set of integrity constraints while an instance is a snap-shot of the data in the database at 
a given instant in time[KS86][EN89]. A relational schema can be thought of as a template 
for the relation. The type definition in programming language notation bears a close 
correspondence to a relation schema [KS86]. The schema is known, in database terms, as 
intention of the relation while the instance is the extension [EN89]. 

In the previous examples (Figure 6 and Figure 7), the Officer relation and the 
Military Unit relation are both examples of a relation instance. Figure 8 shows the relational 
schemas for the Officer and Military Unit relations. Another notation for a schema is a 
listing of the relation’s attributes and their corresponding domains[KS86]: 

* Officer-scheme = (Name : string, SSN : integer. Unit : string) 

♦ Military Unit-scheme = (UnitName ; string. Location : string, CdrSsn : integer) 





Officer 






Name 


SSN 


Unit 




MilitaryUnit 






UnitName 


Location 


CdrSSN 









Figure 8 Sample Relational Database Schema 



17 



In general, integrity constraints are defined for a database schema and should 
hold for every instance of the schema [EN89]. There are several types of integrity 
constraints: key constraints, entity integrity constraints, and referential integrity constraints 
[Da84][EN89][OV91]. Key constraints are concerned with ensuring the uniqueness of key 
values for every tuple in any relation instance of a schema. Entity integrity constraints 
restrict primary key values to be non-null [OV91]. Finally, referential integrity constraints 
maintain consistency between tuples of two relations [OV91]. That is, if a tuple in one 
relation refers to another relation, then it must refer to a tuple that exists in that relation. An 
additional general constraint that is sometimes needed is called a semantic integrity 
constraint [EN89]. In our military example, a semantic integrity constraint would be that 
‘an officer in a unit cannot outrank the commander of his unit’. 

c. Operations 

Three fundamental update operations exist for relations: modify, delete, and 
insert. Delete and insert do what is expected - insert and delete tuples, respectively. Modify 
allows values of some or all attributes of a tuple to be changed. The most important aspect 
in performing these operations is to ensure that the integrity constraints defined for the 
schema are not violated. Therefore, if any integrity constraints would be violated by the 
update operation, then either the operation can be rejected or the system may attempt to 
correct the reason that the operation violates integrity constraints. [EN89] 

It is possible for an insert operation to violate all three of the integrity 
constraints: key constraints, entity integrity constraints, and referential integrity 
constraints. However, the delete operation can only violate the referential integrity 
constraint. Both key constraints and referential integrity constraints can possibly be 
violated by a modify operation. [EN89] 
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2. Formal Query Languages 

Along with Codd’s initial presentation of the relational model in 1970, he also 
proposed two formal query languages: relational algebra and relational calculus [Co70]. 
Before discussing the fundamental differences in the two, it should be noted that it has been 
shown that they are equivalent in expressive power [EN89][OV91]. Thus, any query that 
can be specified in one language can also be specified in the other. Query languages can 
therefore be compared against either of these two to determine if they are relationally 
complete [EN89]. 

Relational algebra, in contrast to relational calculus, is more closely related to the 
underlying system instructions that perform the operations [KS86]. This is the primary 
reason that relational algebra was chosen over relational calculus for use in this thesis. 
Since the two are logically equivalent, it is sufficient to implement only one. Thus, in the 
discussion that follows, relational algebra will be discussed in more detail than relational 
calculus. 

The fundamental difference between the two languages is that of a procedural 
language verses a nonprocedural (or declarative) language. In a procedural language, such 
as relational algebra, the query specifies the sequences of instructions necessary to obtain 
the result. This is in contrast to nonprocedural language, such as relational calculus, which 
specifies a query by delineating what information is desired rather than how it is to obtain 
the information (i.e., the procedure to be followed). [EN89][KS86] 

a. Relational Algebra 

Relational algebra is a procedural language. Therefore, it more directly 
corresponds to the operations necessary to satisfy a query. The set of operations that 
constitute relational algebra are derived from the mathematical theory of sets [OV91]. Each 
operation has as its parameter(s) a relation and returns a result that is also a relation [Da84]. 
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Codd proposed eight operations in his presentation of the relational model in 1970: union, 
intersection, difference, Cartesian product, select, project, join, and divide [Da84]. 
However, it can be shown that of the eight only five are primitive operations; select, project, 
union, difference, and Cartesian product [Da84][EN89][KS86][NMO90]. The other three 
non-primitive operations can be formed by some combination of the five primitive ones. 

(1) Select is a unary operation, taking a relation as its parameter and 
yielding a subset of tuples from that relation as its result. The resultant relation has the same 
relational schema as the input parameter relation. To identify the tuples that are to be in the 
resultant relation, a selection condition (predicate) is specified in the select expression on 
the specified relation. AU tuples in the resultant relation will satisfy the selection condition. 
[EN89][KS86] 

The selection condition is a boolean expression consisting of clauses of 

the form: 

<name of attributexcomparison operatorxconstant value>; 

or 

<name of attributexcomparison operatorxname of attribute> 

where <name of attribute> is the name of an attribute of the input parameter relation; 
<comparison operator> is either =, <, <, >, >, or 9^; and <constant value> is any arbitrary 
number of clauses may be connected with the AND, OR, and NOT operators to form the 
selection condition expression [EN89]. 

In Figure 9, ResultRelation is the resultant relation from performing a 
select operation on the relation Officer (Figure 7) where Unit = 3BDE. The original Officer 
relation had 4 tuples while the resultant ResultRelation has only 2. The selection condition 
can be arbitrarily complex. 
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ResultRelation 



Name 


SSN 


Unit 


Rothlisberger 


123-45-6789 


3BDE 


Spear 


550-34-2453 


3BDE 



Figure 9 Example Result of a Select Operation 



(2) Project is also a unary operation. The project operation uses an attribute 
list to select the attributes that will appear in the resultant relation. The attribute list must 
be a subset of the attributes of the input parameter relation. The schema of the resultant 
relation in this case is not the same as the input parameter relation. The attributes are a 
subset of the attributes in the input parameter relation. However, the attributes in the result 
will be listed in the order that the attributes are listed in the attribute Ust. However, the 
resultant relation will have the same number of tuples. [EN89] 

In Figure 10, ResultRelation is the resultant relation from a projection 
operation of the Name and SSN fields of the Officer relation (Figure 7). The original 
Officer relation has three attribute fields while the resultant ResultRelation only has two. 
However, both relations have the same number of tuples. 
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ResultRelation 



Name 


SSN 


Rothlisberger 


123-45-6789 


Nash 


241-4500974 


Spear 


550-34-2453 


Walter 


233-45-3423 



Figure 10 Example Result of a Project Operation 



(3) Union, in contrast to the first two operations, is a binary operation. It 
along with the operations difference and Cartesian product are the standard mathematical 
set operations [Da84][EN89]. Thus, the union of two relations is a resultant relation that is 
the set of all tuples that belong to either relation or to both. This operation, along with the 
difference operation, can only be executed if the two input parameter relations are union 
compatible. That is, they must have the same number of attributes (the same degree) and 
the corresponding attribute must be based on the same domain (although they need not have 
the same name) [Da84]. As an example, two union compatible relations are shown in 
Figure 1 1 . The resultant relation has the same degree as the input relations. Note that the 
order of the attributes in the relations is important for checking union compatibility. 



22 



OfficerReserve 



FirstName 


LastName 


Ron 


Spear 


James 


Schledorn 


Leonard 


Tharpe 



EnlistedActive 



Fname 


Lname 


James 


Justice 


John 


Walter 


Luther 


Moen 


Jane 


Pauli 


James 


Schledorn 



ResultRelation 



first_name 


last_name 


Ron 


Spear 


James 


Schledorn 


Leonard 


Tharpe 


James 


Justice 


John 


Walter 


Luther 


Moen 


Jane 


Pauli 



Figure 11 Union Compatible Relations and Result of Union 
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(4) Difference, given two input parameter relations, A and B, produces a 
resultant relation which is comprised of all tuples in A that are not in B. As with the union 
operation, the input parameter relations A and B must be union compatible. Therefore, the 
difference of relations OfficerReserve and Enlisted Active (from Figure 11) is shown in 
Figure 12. However, the difference of EnlistedActive and OfficerReserve would be a 
resultant relation that contains all of the tuples in relation EnlistedActive except for the last 
tuple which contains James Schledorn and no tuple from OfficerReserve. 



OfficerEnlisted 



first-name 


last-name 


Ron 


Spear 


Leonard 


Tharpe 



Figure 12 Result of Difference Operation on Relations in Figure 1 1 



(5) Cartesian Product, the last of the set operations, differs from the 
previous two operations, union and difference, in two main ways. First, if the Cartesian 
product operator is operating on relations A and B which have 2 tuples with 3 attributes and 
5 tuples with 4 attributes respectively, then the resultant relation will have 10 (2 * 5) tuples 
and 7 (3 + 4) attributes. In our previous example (Figure 1 1), the Cartesian product of the 
two relations would have a resultant relation with 15 (3 *5) tuples and 4 (2 + 2) attributes. 
Secondly, the two input parameters to this operation need not be union compatible. 

b. Relational Calculus 

While relational algebra is founded on the mathematical principles of set 
theory, relational calculus (a procedural language) is founded on first order predicate 
calculus [EN89]. Two well-know forms comprise the relational calculus; tuple relational 
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calculus and domain relational calculus. There is a strong similarity between the two forms. 
As their names imply, tuple relational calculus is the form in which variables represent 
tuples while domain relational calculus uses variables to represent attribute domain values 
[KS86]. In tuple relational calculus, the database is viewed as a set of tuples, while in 
domain relational calculus it is viewed as a set of domains. Thus, meaning is given to 
queries by interpreting variables as assertions on the database [OV91]. 

3. Other Query Languages 

SQL, QUEL, and QBE are three commercial query languages that expand on the 
formal languages previously discussed, relational algebra and relational calculus. Both 
SQL and QUEL are relationaUy complete languages, however, some implementations of 
QBE are not (they lack explicit universal and existential quantifiers) [EN8 9]. In general, 
they provide a higher level, more friendly user interface along with other facilities for data 
definition (a data definition language function, DDL), data manipulation (data 

manipulation language facilities, DML), and security constraint specification [KS86]. It 
is considered beyond the scope of this thesis to discuss these other areas. However, each of 
these languages will be reviewed very briefly in this section to give the reader a feel for 
considerations in implementing a commercial query language. All of these languages are 
more declarative than procedural. 

a. SQL 

The Structured Query Language, SQL, is still referred to as Sequel 
(Structured English QUEry Language) by many people and is probably the most well 
known of the three. SQL combines constructs from both relational algebra and calculus 



12. Although, each language does not necessarily provide for all of these facilities. 
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[EN89][KS86]. It has become somewhat of a defacto standard relational database 
language. Queries in SQL can be interactive or embedded in an application [Da84], 

The basic format for a SQL query is: 

SELECT <list of attributes> 

FROM <list of tables> 

WHERE <condition> 

where <list of attributes> is a list of names for which values are desired (corresponds to the 
relational algebra project operation), <list of tables> is a list of required relations necessary 
to satisfy the query, and <condition> identifies the tuples desired by evaluation of a boolean 
expression (corresponds to the relational algebra selection condition in a select operation 
[EN89]. 

One departure from the formal relational models is that SQL allows tuples 
within a relation to be repeated. Thus, a relation in SQL is not a set of tuples but a multiset 
(or bag) [EN89]. 

Some current work in the area of query languages is being done using the idea 
of a graphical interface for constructing queries. One such effort attempts to overcome the 
difficulties in forming SQL queries (ease-of-use) by designing and implementing a 
relationally complete graphical dataflow query language (DFQL) [C191]. 

b. QUEL 

QUEL has similar functionality to SQL; however, instead of combining 
constructs from both of the formal languages, it closely parallels tuple relational calculus 
[KS86]. Three types of clauses are generally used to construct most QUEL queries: range 
of, retrieve, and where [KS86]. Range of explicitly declares the tuple variables, retrieve 
declares the attribute to retrieve (corresponds to projection attribute list), and where 
specifies the selection condition [EN89]. 
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c. QBE 



Query by Example, QBE, is most closely related to domain relational 
calculus. It is unique in that it is a two dimensional language: skeleton tables (displaying 
the relation schema) are displayed pictorially, and queries are then expressed by filling in 
an example row(s). When looking at a QBE query, constant values appear without any 
special markings or indicators while domain variables (which do not have to match any 
specific database values and are completely arbitrary) are indicated by being preceded by 
an underscore (“_’). To specify that the values of a certain column are to be retrieved, the 
prefix ‘P.’ (for print) is used. [EN89][KS86] 

D. OBJECT-ORIENTED DATABASES 

As with object-oriented programming, the relatively new area [Ne90a] of object- 
oriented databases (OODBMS) does not as yet have a formal definition/specification or 
even an agreed upon informal definition/specification [Ed91][US90]. “Object-oriented 
databases = object orientation -i- database capabilities” [Kh91, p. 31] is one attempt to 
define OODBMSs where the database capabilities alluded to include persistence, 
transactions, concurrency control, recovery, querying, versioning, integrity, security, and 
performance issues [Kh91]. This could be rewritten as object-oriented databases = object- 

oriented + database capabilities^^. 

This section provides a general description of OODBMS concepts along with a 
discussion on several OODBMSs currently available: IDB, Ontos, Vbase, Gemstone, and 
POSTGRES. Of the systems looked at, only IDB will be given more than a cursory look 



13. [Kh9l] defines object orientation as abstract data types + inheritance + object identity, which is 
essentially the same definition previously used in this paper for object-oriented. For a more in-depth 
discussion of OODBMS concepts see [US90]. 
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since it is the system used to implement the Relational/Object-Oriented Database 
Management System in this thesis. 

1. Object-Oriented Model Concepts 

The most well known data modeling model is the Entity-Relationship (ER) data 
model. Until the late 1970s, this model was sufficient for supporting the modeling needs of 
conventional DBMSs (hierarchical, network, and relational systems) that meet traditional 
business data processing requirements [EN89]. The ER data model is a high-level model 
used prior to actually developing a database schema in a specific DBMS. As modeling 
needs have become more complex, the ER data model has become increasingly inadequate. 
To meet the needs for complex data models, many data models have been proposed. Of 

those proposed, they generally fall into three categories; semantic data models^^, functional 
data models, and object-oriented models [EN89]. 

In conventional DBMSs, data is modeled using the classical record-oriented ER 
model. Here data is looked at as a group of relations (or record types) that are comprised of 
a group of tuples (or records) which are all stored in a file [EN89]. Thus, the ER model must 
be converted into a DBMS specific model (or schema) which may lose its resemblance to 
any real world entities (or objects) during the conversion process. A good example is that 
of an ER model for a relational database application which is converted to a group of 
relations that are then normalized. In the normalization process, the original model may be 
distorted to such an extent that any relationship to the original real world entities being 
represented in the database application is lost as information is scattered among relations 
[EN89]. 



14. [EN89] provides an detailed discussion of what they term the enhanced-ER model (EER) which 
encompasses what they consider the most important concepts of the semantic data model. 
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Of the models mentioned above, we focus on the object-oriented data model. 
With an object-oriented model, a database is considered group of objects that represent real 
world entities [EN89]. In OODBMSs, objects are represented directly by database objects 
[EN89]. Thus, there is no loss of the original model as with the ER model; as more complex 
real-world entities are modeled using complex objects, there is a direct correspondence 
between a real-world entity and its database representation. This direct correspondence 
allows objects to maintain their integrity and identity which in turn allows the objects to be 
identified and operated upon [EN89]. Some have gone so far as to question whether it is 
meaningful to talk about an object-oriented data model [Ki90] since object-oriented data 
model concepts and the object-oriented paradigm are for all practical purposes the same. 

Fundamental object-oriented data model concepts include data abstraction, 
encapsulation, object identity [Mc91], inheritance, complex objects, message passing, and 
operator overloading (or polymorphism) [Ki90]. All of these concepts, with the exception 
of object identity, were specifically addressed previously in this chapter under object- 
oriented programming concepts. Generally, each object is represented by an object 
identifier that is system generated. The identifier is independent from any key attributes 
which allows attributes to be modified without destroying the objects identity. [EN89] 

2. Object-Oriented Database Systems 

Persistence of objects is considered the primary difference between OOPLs and 
OODBMSs [EN89]. Objects used in an OOPL program exist only during program 
execution whereas those in OODBMSs must exist permanently in secondary storage from 
session to session. Thus, the OODBMSs and OOPLs are quite similar except for additional 
facilities provided by the OODBMS system. By the same token, OODBMSs have similar 
advantages as those of OOPLs; expressibility, reusability, etc. 
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“The Object-Oriented Database System Manifesto” written in 1989 by M. 
Atkinson, F. Bancilhon, D. DeWitt, K. Kittrick, D. Maier, and S. Zdonik for the First 
International Conference on Deductive and Object-oriented Databases, Kyoto, Japan, 
describes 13 mandatory characteristics. Listed in Figure 13, for a database system to be 
considered an OODBMS [Ed91]. 



1. supports complex objects 

2. supports object identity 

3. encapsulates objects 

4. supports either types or classes 

5. classes or types inherit from their ancestors 

6. do not bind prematurely 

7. are computationally complete 

8. are extensible 

9. data is persistent 

10. manages very large databases 

11. allow concurrent users 

12. recover from software and hardware failures 

13. have a simple way to query data 

Figure 13 OODBMS Manifesto 



15. This does not contain an agreed upon set of characteristics, rather, it is an attempt to offer char- 
acteristics for agreement within the database community. 
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There are some correlations that may be made between RDBMS and OODBMSs 
that help to conceptualize how some of the object-oriented paradigm relates to the 
relational paradigm. A row in a relation may be thought of as an object in an OODBMS. 
The set of rows of a relation may be equated to a class. Other concepts in OODBMSs that 
have no correlation to anything in a relational system include: methods, object identifiers, 
inheritance, and encapsulation. However, OODBMSs do not have a mathematical 
foundation to stand on as relational systems do. [Ed91] 

3. IDB Object Database Overview 
a. General Information 

IDB [Pe91a][Pe91b][Pe91c][Pe91d] is a new OODBMS that first entered the 
commercial market in 1990 . However, it could be considered to have been in development 
for over a decade with the design and architecture of the Interface Description Language 
(DDL), a subset of which is a fundamental component of the IDB system. IDB was built 
from the ground up as an object database management system. This is in contrast to some 
other database management systems that claim to be object-oriented but are not ‘real’ 
object-oriented systems. Some of these are systems that have as their kernel or core a 
relational system that has object-oriented extensions added on top. Others claim to be 
object-oriented but fall short in fully implementing the concepts that comprise the object- 
oriented paradigm: inheritance, encapsulation, polymorphism, and abstract data types. 

The current version of IDB is 1.1. Version 1.0 ran on several platforms: 
Domain OS (680X0), Sun 3 (680X0), Sun SPARC and Windows 3.x. Version 1.1 extends 
this list to include the Macintosh, NeXT, and HP-UX (680X0 and PA-RISC). Other key 
differences between the version 1.0 and 1.1 include: supported platforms that are 
networked together can now share data over the network; attributes may be removed from 
a schema without having to modify the ASCII form fUe; ease of access to menu facilities 
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has increased; development tools may be used with Windows 3; and bugs have been 
removed that existed in version 1.0. [Pe91b] 

Persistent Data Systems, the designer and developer of IDE, describe IDE as 
“an object database for software developers who build applications that must manage 
complex shared data”[Pe91d, p. 3]. Applications suited for use with IDE include CASE, 
CAD, image management systems, hypertext systems, hypermedia systems and geographic 
information systems. This list is not intended to be all inclusive, but rather to give the reader 
an idea of the types of applications with requirements to model, manage, and store complex 
and unconventional data. [Pe91d] 

The data definition language (or schema language), IDL, extends Kernighan 
and Ritchie (K&R) C [KR78] to include object-oriented capabilities. Polymorphism, 
multiple inheritance, and dynamic binding and loading are among these capabilities. 
Eecause IDE uses K&R C, tools available for working with C (such as the C compiler and 
on-line debugger) on each supported platform may be used in the development of EDE 
applications. [Pe91d] 

IDL facilitates the interface between C and IDE. The interface can be thought 
of as consisting of three parts: core interface, display manager interface, and browser 
interface. The core interface allows IDE applications to have object-oriented capabilities. 
Display management for stand alone applications uses the display manager interface. This 
interface is not exclusive to stand alone applications since its features can also be accessed 
from within the browser. The browser interface has the features of the display manager 
interface in addition to other special features only available in the browser. [Pe91d] 

b. Clusters and Structures 

A key concept in IDE is that of a ‘cluster’. This term is used in both the 
logical and physical sense. That is, the term cluster when used in the context of computer 
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science generally brings to mind clustering in memory. However, the word cluster in the 
strict sense means to gather things together. In IDB, a cluster is a gathering of objects or a 
group of objects. An object cannot be in more than one cluster. Since IDB is built as a multi- 
user system, it also includes facilities for concurrent access control. Clusters are important 
in maintaining the access control. “The cluster is the unit of data transfer and the unit of 
locking for control of concurrent access” [Pe91d, p. 3]. 

Persistent Data Systems describes an IDB database as “a set of objects 
connected by references” [Pe91c, p. 6]. Since a cluster is a group of objects, then an IDB 
database is simply a set of clusters connected by references. There are two kinds of 
references in IDB: local references and cross references. The names themselves are quite 
descriptive. Local references are those references between objects of the same cluster. 
Cross references, on the other hand, are between objects belonging to different clusters. 
[Pe91d] 

Access to clusters is gained by opening a transaction on the cluster. It is at this 
time that the cluster is read in from secondary storage into main memory. Local references 
are made by using pointers to the object being referenced. Cross references may also use 
pointers if the cluster containing the object they reference is already present in memory 
(i.e., a transaction is also open on that cluster). The other possibility is that the object being 
cross referenced is not in main memory. This case is resolved by using unique identifiers 
that IDB issues to every object. [Pe91d] 

IDB guarantees that every object created will have a unique identifier. This 
identifier is not only unique to the cluster, system, platform, etc.; it is unique universally. 
That is, an object created by IDB on any platform can be ported to any other platform and 
still be guaranteed that the identifier is unique. This allows different platforms networked 
together to share IDB files without object identification problems. Thus, “no two objects 
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will ever have the same identity and an object will maintain its identity even when moved 
from place to place” [Pe91d, p. 4], 

Several identifiers are needed to accomplish this: master identifiers (MID), 
cluster identifiers (CID), object identifiers (OID), and local identifiers (LID). During 
installation, a unique MID is set up that is assigned to each copy of IDB by Persistent Data 
Systems. When a cluster is created, the MID is combined with further numerical identifiers 
to form the CID. Finally, the OID is composed of the CID and the LID which uniquely 
identifies the object within the cluster. [Pe91d] 

Each cluster is described by an Interface Description Language (IDL) 
structure. The structure contains all the necessary types to describe the objects of a cluster. 
In other words, it contains the schema for the cluster specified in IDL. The IDL structure is 
really the “description of structural constraints on data” [NMSW83, p. 7]. The fundamental 
IDL model is predicated upon the directed attribute graph. An example of a directed 
attribute graph is given in Figure 14. 

A directed attribute graph is composed of a set of typed nodes that possess a 
set of attributes. The type of a node determines the particular set of attributes it will contain. 
The attributes are either a primitive value (the value is embedded in the node and is either 
boolean, integer, or rational) or a node-value (a pointer to another node). In Figure 14, the 
attributes with node-values have pointers which are the directed edges in the graph pointing 
to other nodes. Each graph must have a root node that allows all other nodes to be reached 
by following some path along different attribute edges from the root to the nodes. “An IDL 
structure specifies a related class of attributed directed graphs by listing the set of node 
types, the attributes of each node type, and the type of the root” [NMSW83, p. 7]. 
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Figure 14 An Example of a Directed Attribute Graph [NMSW83, p. 8] 

c. Nodes, References and Attributes 

Every EDB object must have a type and can only be in one cluster. The types 
that an object may have are defined through the class structure that is delineated in the 
cluster schema. In IDB, only classes which have no subclasses can be instantiated as 
objects. These classes are called nodes and have the type node type. In the class hierarchy, 
the nodes are the leaves of the class structure. This is something of a departure from the 
standard object-oriented concept of a class since only leaf classes can be instantiated. 



35 



However, any class that is not a leaf can always be made a leaf (in a logical way) by 
instantiating a subclass of the class to only inherit all attributes and methods of its 
superclass. That is, it is a leaf which is a copy of its superclass except that the superclass 
has subclasses and the leaf (by definition) does not. Other class t)^es that are not node types 
are said to be strict class types. 

Consider the graph presented in Figure 15, which is derived from the example 
IDL schema (included as APPENDIX A) from the IDB User’s Manual [Pe91d, p. 32]. It is 
clear from the graph that the leaf nodes are ptrain, ftrain, fplane, and pplane. These classes 
are IDB node types and may be instantiated to IDB objects. The other classes are used to 
build the attributes and methods of the node types but may not be instantiated into objects. 
These strict class types delineate attributes and methods that are common to all of their 
descendants [New86]. IDB also supports the idea of multiple inheritance. Thus, in our 
example, ptrain inherits all of the attributes and methods of class types passenger and train. 




Newcomer likens the IDL node type to the idea of a record type in other 
languages[New86]. Record fields are similar to a node’s attributes[New86]. There are two 
kinds of references which connect objects; local references and cross references. All 
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references must also have a type; however, unlike objects which can only have node types, 
references can have the type of any class in the cluster. A references of a certain type can 
point to any class of that type or any of its descendants (if the class is not a node). Thus, a 
reference of type train, in Figure 15 above, could point to a train, a ptrain, or a ftrain. 

From the root reference of any cluster, all objects within that cluster must be 
reachable by following some path along references in the cluster. Two objects may have 
attributes that reference the same object. In this way, references facilitate sharing. 
References are also allowed to create cycles within a cluster. 

There is another possibility for the type of a reference; universal types. The 
types discussed up to this point have all been associated with a particular cluster. Universal 
types allow references to refer to an object in any cluster. The universal types and their 
relation to each other is shown in Figure 16. [Pe91c] 
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d. Transactions 



Since IDB is a multi-user system, concurrency control must be maintained. 
Transactions are used to implement concurrent access control to clusters. Additionally, 
transactions guarantee that cluster updates are all or nothing. That is, the entire cluster is 
updated or nothing in the cluster gets updated. Thus, cluster modifications are ‘atomic’. 
[Pe91c][Pe91d] 

Transactions allow users to read and write clusters. Access to a cluster is 
determined by one of four types of transactions; write, create, read, and examine. To 
modify an object, a write transaction must be open. Examine and read transactions allow 
different forms of parallel access to a cluster by one or more user. New cluster values are 
created by the create transaction. A series of ‘roll-back’ points may be established by nested 
write transactions. An arbitrary number of write transactions may be nested within other 
create or write transactions. Large and complex modifications are facilitated in this manner. 
[Pe91d] 

Reading and traversal of cluster objects and the ability to use those objects 
and their associated attributes to set values of browser variables is possible during read 
transactions. While a read transaction is open on a cluster, no write or create transaction on 
that cluster is allowed. Similarly, only while no write or create transaction is open, may a 
read transaction be opened. This guarantees that the cluster being viewed in memory is the 
same as that cluster on secondary storage. 

Examine transactions are similar to read transactions except that it does not 
stop a write transaction from being opened and/or committed on the same cluster. Thus, the 
cluster being viewed in memory may be different (older) than that cluster on secondary 
storage. This transaction can be opened at any time. It allows a greater amount of 
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concurrent use of the system. Clearly, this kind of transaction should only be used when 
viewing the most current instance of the database is not necessary. 

Modification of cluster objects and their associated attributes is accomplished 
using either a create or write transaction. Modifications made to the cluster are not written 
back to secondary storage until the transaction is committed. If after modifying the objects 
of a cluster in memory, it is determined that the modifications are unwanted, then the 
transaction may be aborted. In this case, that cluster in secondary storage remains 
unchanged. It is important to note that during a write or create transaction, one or more 
examine transactions may be open on the same cluster. 

A special case of the write transaction is the create transaction. Create 
transactions may only be opened during entry to a cluster. They are used if no cluster file 
exists on secondary storage or if the cluster file that does exist is no longer wanted. The 
create transaction creates a legal value to which the cluster root is set. Once the create 
transaction is committed, then the created cluster and any other objects created during the 
open transaction are written to the cluster file on secondary storage. 

4. Other Systems 
a. ONTOS/Vbase 

Vbase, a single-user system, a product of Ontologic Inc. (now named Ontos 
Inc.) released in 1988, had several problems that caused it to flop. First, it had several 
language problems. The Type Definition Language (TDL) was a nonstandard language 
which was plagued by many inherent problems associated with nonstandard languages. 
TDL was used for schema definition and abstract object interface specification [HW91]. 
Their object manipulation language was an object-oriented extension of the C language, 
called a compiled procedural language (COP) [HW91]. In addition to impedance 

mismatch problems produced by these languages, Ontologic had to do everything to 
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support the languages and the languages had not passed the test of time. Additionally, there 
was a lack of tools needed to work with the languages. [In89] 

ONTOS is the successor to Vbase [AHS91]. It runs under UNIX, ALX, or OS/ 
2 [In89]. The design goal of ONTOS is that the system should allow trade-off decisions 
between performance, formalism, and safety to be made by the user [AHS91]. The system 
allows the user to directly access objects through direct references. In this manner, the user 
may bypass system mechanisms, controlling low-level detail to enhance performance if 
deemed critical to performance. ONTOS also supports C-i-i-, overcoming the nonstandard 
language problem of Vbase[In89]. Additionally, it provides a class library to enhance its 
modeling power. It also has no need for a schema definition language since it operates on 
class definitions in C-h- directly. Versioning, an alternative mechanism, a graphical 
browser, an integrated object SQL, and a multi-user capability on a homogeneous network 
also exist in ONTOS. [AHS91] 

b. GemStone 

The Servio Logic Corporation produces GemStone^^ [BM089][HW91], a 
disk-based storage manager designed for commercial and engineering markets [BOS91]. 
The designers of GemStone surveyed object-oriented extensions to C, Pascal, and the 
OOPL Smalltalk before deciding to develop their own OOPL, OPAL, a modified version 
of SmalltaIk-80 [HW91]. OPAL is GemS tone’s data definition language/data manipulation 
language, which is also used for general computations/queries [BM089]. Since it only uses 



16. When information must pass between two structurally and semantically different languages im- 
pedance mismatch may occur [HW91]. Database systems that use two different languages in their 
implementation often have one that is a procedural language (conventional) and the other a more de- 
clarative, higher-level language which results in a mismatch of two language paradigms [Kh91]. 

17. The current version of GemStone is Release 4.0 
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one language, OPAL, for programming, it bypasses the problem of impedance mismatch 
[HW91]. GemStone provides an interface to several procedural languages; C, C++, and 
Smalltalk [BOS91]. 

Visual Schema Designer (GS Designer) and Tool Suite are two graphical 
tools which are included with GemStone. The GS Designer allows GemStone class 
definitions to be modified, deleted, and created using a keyboard and mouse interface along 

with bitmapped graphics in a windows environment. The class graph^^ is the primary 
organizing principle of the GS Designer. Both a high-level application development 
environment and a visual programming environment are integrated by the graphical tool 
‘tool suite’. Motif and OpenLook are both supported by tool suite. [BOS91] 

Recently, Servio Corp. introduced a collection of development tools that 
facilitate object-oriented financial, scientific, and manufacturing systems construction by 
application developers. This tool collection is called the GemStone Object Database 
Development Environment, Geode. Geode is comprised of four components: the forms 
designer, the visual program designer, the application designer, and the system 
programmer tools. The forms designer facilitates the construction of screens for database 
information display, update, and insertion. The visual program designer comes with a set 
of basic libraries, which may be extended by the user, and applications to be developed 
graphically without writing code. The products of both the forms designer and the visual 
program designer are combined into complete applications by the application designer. 
Finally, debuggers, cross-reference tools, graphical browsers, and performance profilers 
comprise the system programmer tools. [Sc91] 



18. A named group of classes interrelated by various types of relationships (including generalization, 
association, and aggregation) is called a class graph. All GemStone class graphs have the predefined 
Object class as its root. [BOS91] 
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GemStone supports several relational gateways. That is, it supports SQL 
access to the external databases Sybase, Ingres, Oracle, and Informix. SQL query results 
may be viewed as objects using these gateways which provides interoperability with 
relational databases. The translation between the systems is facilitated using generic row 
(tuple/record) and relation classes that may be specialized by the user by defining 
subclasses these generic classes. [BOS91] 

c. POSTGRES 

POSTGRES*^ is the successor to the INGRES relational DBMS, and has 
been under development since 1986 under the leadership of Professor Stonebraker at the 
University of California, Berkeley [St91b][SK91]. POSTGRES is often listed under the 
heading of OODBMSs. However, it is more than that since it also supports knowledge 
management. Actually, it is an extension of the traditional RDBMS that supports complex 
objects; inheritance; methods and functions in the database; and contains both a complete 
rule system and an abstract data type system [St91b]. POSTGRES II, the successor to 
POSTGRES is in the design process and will try to manage main-memory data, disk-based 
data, and archive-based data in a unified, elegant manner [BOS91]. 

The objectives of the designers of POSTGRES are to [Da90]: 

♦ provide better support for complex objects, 

♦ provide user extendability for data types, operators, and access methods, 

• provide active database facilities (alerters and triggers) and inferencing 
support, 

• simplify the DBMS code for crash recovery. 



19. POSTGRES stands for Post INGRES and its current version is 3.0 [RK][SK9l]. 
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• produce a design that can take advantage of optical disks, multiple-processor 
workstations, and custom-designed VLSI chips, and 

• make as few changes as possible (preferably none) to the relational model. 

E. PREVIOUS WORK 

In 1988, Michael L. Nelson completed the fundamental work in this area. Nelson’s 
primary goal was to design a Relational Object-Oriented Management System (ROOMS) 
that could be implemented in almost any commercial object-oriented database or any 
object-oriented programming language [Ne88]. Stephen C. Filippi expanded the work done 
by Nelson with the completion of his Master’s Thesis, Implementing Relational Operations 
In An Object-Oriented Database, in 1992 [Fi92]. 

1, ROOMS 

ROOMS is the foundation upon which this thesis is built. ROOMS is a feasibility 
study to show that the relational data model need not be discarded in moving to object- 
oriented systems, and to allow the additional capabilities of the object-oriented paradigm 
realization within conventional applications by removing limitations on data types 
[Ne88][NMO90]. 

The fundamental structure of ROOMS is almost as simple as the relational system 
it imitates. An object that is a collection of tuples (records) is a relation. An object that is a 
collection of fields is a record. Objects that are user-defined class instantiations are fields. 
In ROOMS, all records of a relation must have identical format. Distinction between 
complex and simple objects are not made: no data type limitations. [Ne88][NMO90] 

To show that ROOMS is feasible, the five fundamental relational algebra 
operations (selection, union, set difference, Cartesian product, and projection), which 
constitute the basis for all other relational operations, were implemented in a LISP-based 
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OOPL, PC Scheme (PCS). However, PCS has no facilities for object persistence so the data 
in this implementation is lost from one session to another. [Ne88] 

2. Implementing Relational Operations in Prograph 

This work continues the concepts of ROOMS by implementing the five 
fundamental relational algebra operations in Prograph, an OOPL. The fundamental 
contribution of this work is that of object persistence. Even though Prograph is not an 
OODBMS, it contains primitive operations that allow for reading and writing database files 
to secondary storage and for complex data type manipulation [Fi92]. The natural step that 
follows is to actually implement ROOMS in a commercially available OODBMS, which is 
the thrust of this thesis. 
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ni. DETAILED PROBLEM STATEMENT 



A. GENERAL 

The focus of previous chapters has been to provide the reader with a very brief 
introduction to the motivation and topic of this work, a discussion of fundamental concepts 
necessary for a more complete understanding of this thesis, and a point of departure for this 
and future chapters. The purpose of this chapter is to provide an overview of some 
limitations associated with RDBMSs and OODBMSs, along with a discussion of the 
rationale for a combined R/OODBMS approach. In general, the limitations of RDBMSs 
tend to be the strengths of OODBMSs and the limitations of OODBMSs the strengths of 
RDBMSs. 

B. RELATIONAL DATABASE LIMITATIONS 

RDBMSs use a very simple data structure, the idea of a table (rows and columns), and 
are based upon a strong mathematical foundation, predicate logic and set theory. Primarily 
because of these two factors, RDBMS became widely accepted for business applications 
over the older and more awkward hierarchical and network database technologies. 
However, RDBMSs have a severe limitation: the inability to deal with complex data. It is 
the RDBMS’s simplicity, along with its mathematical foundation and its complex data 
limitation, that are basis for this thesis. 

1. Simple Data Types 

For years, RDBMS have provided excellent performance for traditional, well 
established business data processing applications. Their standard fixed collection of data 
types (integers, rationals, strings, etc.) were sufficient to allow RDBMSs to function well. 
Now, as more complex data needs have developed within the business sector, particularly 
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in the engineering arena, it has become clear that this simple collection of data types is no 
longer adequate. Although relational systems have not outgrown their usefulness as 
traditional business database needs will always exist, there is definitely a need for 
something to overcome their limited data types. 

Some current RDBMSs provide the ability to include digitized pictures in their 
database applications. However, none provide the ability to include more complex data 
structures such as sounds, animated graphics, and extremely large and complicated inter- 
relationships among relations within a database, to name some of the primary ones. 
Although some relational systems have been extended to include some of these complex 
data types, they generally do not include inheritance, encapsulation, and other 
characteristics of the object-oriented paradigm. 

As RDBMSs attempt to maintain more complicated data relationships, 
performance of the system is degraded. The normalization process used in designing the 
database schema to represent complex data cause many small relations to exist within the 
database. As queries are made of the database, many join operations are then needed to 
answer the query. Since join operations are very expensive in terms of performance, the 
system tends to provide poor performance. However, in OODBMS this problem is avoided 
since these complex relationships can be represented with complex objects that have an 
explicit link between component objects. Thus, the need for numerous joins is avoided and 
performance is increased. 

When modeling real world entities, the relational model uses relations (flat 
objects) to represent them. During the normalization process, the relations in a database 
schema are further flattened out into a number of smaller relations. This decomposition of 
real world entities into smaller flat relations represents a loss of abstraction. For example, 
in the previous chapter there was a real world entity that was represented by the relation 
Officer in a military database. A database containing the Officer relation might also have a 
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relation called Dependents to represent the real world entities that are dependents of 
military officers. However, this is not a very good abstraction. A better abstraction for these 
two real world entities in a military database is to have the Officer relation contain one more 
attribute: Dependents. But, this attribute would be multi-valued which is not consistent 
with the requirement that all attributes in a relational database be atomic. Therefore, multi- 
valued attributes are not supported in RDBMSs. 

Continuing with the previous example, it can be seen that when an Officer tuple 
is retrieved there is direct access to the dependent data also. However, if two relations were 
used, then a join operation would be needed to associate an Officer tuple with that officer’s 
associated dependents. This is a very simple example; however, the reader can imagine that 
if the complexity of this type of situation is increased several orders of magnitude, then 
surely a RDBMS would provide poor performance in responding to queries of this nature. 

2. Tuple Function 

As stated previously, relational databases are based on the simple data structure 
of a table of values of simple types. Displaying the values of a tuple in a relational database 
system is generally straight forward since the values are generally simple text or numbers 
that the database can easily handle with ASCII characters. For traditional business data 
processing applications, this is certainly sufficient. However, databases that contain more 
complex attribute values (such as sounds, graphics, video, etc.) are not so simple. 

Consider a database of machine parts that contains as an attribute a 3-D image of 
each part along with more traditional attributes, cost, part number, size, weight, quantity on 
hand, etc. If a user wants to display a the 3-D image of a particular part, then the part tuple 
retrieved requires some method of displaying this attribute since a general RDBMS that 
was not designed for this specific application will not be able to display this attribute. 
However, an OODBMS could handle this situation by having a Display method for Part 
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objects which would display the 3-D image. Since OODBMSs^ allow objects to have 
methods defined for them, any OODBMS would suffice to construct and maintain this 
machine parts database. This is in contrast to a RDBMS that would have to be developed 
specifically for this application since the data does not contain any functionality that could 
be used to determine how to handle it. 

3. Inheritance 

Relations in a relational database lack the ability to define a new relation based on 
an existing relation. That is, a new relation cannot be created that has a schema that only 
lists new attributes to be added to the schema for an already existing relation. For example, 
assume that a relational database has a relation called Person that has the following 
attributes: name, weight, birthdate, color eyes, and color hair. Now we wanted to add a new 
relation. Officer, that has all the characteristics (attributes) of Person but also has attributes 
rank, branch of service, and unit. It is desirable to allow Officer to inherit the attributes of 
Person. The usefulness of inheritance is more evident if we consider that we also want to 
have another new relation. Enlisted, that has the characteristics of Person along with 
enlistment date, rank, ETS, etc. Now we have two relations that have the characteristics of 
Person but do not have to redefine the common Person attributes in each of the new 
relations. In a relational system, these common attributes cannot be inherited but each new 
relation has to have them explicitly included in their schema. 

Using the object-oriented paradigm, inheritance is included by definition and 
supports code/schema reuse by allowing an object to be further specialized by the definition 



1. It is realized that there is no standard definition for an OODBMS however, in all cases it is gen- 
erally agreed that for a DBMS to be considered object-oriented that it must manage objects that have 
attributes and methods associated with them. 
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of a subclass that inherits all of the attributes of its superclass. In our example, both Officer 
and Enlisted would be subclasses of the class Person. Now, any instance of an Officer or 
an Enlisted will include the common Person attributes without having them explicitly 
defined in the class definition for Officer or Enlisted. 

4. Impedance Mismatch 

With many conventional database systems (relational, hierarchical, and network), 
there is generally the problem of impedance mismatch. That is, they generally have one 
language for data queries and another for data manipulation. In the relational case, a query 
language like SQL may be used but then the actual data in the database is manipulated using 
a conventional programming language. Thus, there is a mismatch by mixing the generally 
procedural conventional language with the more declarative query language along with 
their differing data structures [Kh91]. In OODBMSs, there is a closeness between data and 
programs where a single language has the expressive power and flexibility to allow both 
data queries and manipulation. 

C. OBJECT-ORIENTED DATABASE LIMITATIONS 

Many feel that OODBMSs are here to stay and that they are the next logical step in 
the evolution of database technology. However, there still exist two primary drawbacks to 
them which limit their acceptance as the answer to tomorrow’s database requirements: (1) 
the lack of a theoretical basis and (2) no universally accepted standard definition. Neither 
of these limitations exist in relational database model which has played a large role in the 
overall acceptance of relational model. Thus, there is no reason why a more expressive and 
powerful model that can easily have relational databases mapped onto it and overcomes 
these limitations cannot become widely accepted for tomorrow’s applications. 
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1. Mathematical Foundation 



Any query language in a relational system must be relationally complete^. Thus, 
RDBMS users are guaranteed that their queries will be answered correctly by any RDBMS 
system since relational algebra is based on mathematical set theory and relational calculus 
is based on mathematical predicate logic [EN89]. Queries in any language can be reduced 
to a mathematical premise and be mathematically shown to be true. This is not the case with 
OODBMSs which have no such theoretical basis. 

2. Standardization 

Possibly more serious than the non-existence of a formal theoretical basis is the 
lack of a universally accepted standard definition, which may be considered one of the 
relational model’s stronger features. Since relational databases have a universally agreed 
upon definition and underlying theoretical foundation, different commercial RDBMSs are 
functionally equivalent. Standardization leads to many advantages such as better support, 
portability among different systems, greater acceptance, common evaluation criteria, etc. 
The OODBMS community lacks anything close to a standard or even a generally accepted 
definition. 

Not only is there no standard definition or specification, but the object-oriented 
community cannot even agree upon terminology [Ed91][Ne91]. It is even more difficult to 
define something when people cannot even agree on the terminology that is used to 
describe it. Thus, when a database or any other software product is said to be object- 
oriented, the user cannot be sure what that means. Since ‘object-oriented’ is a hot 



2. Recall that relational calculus and relational algebra are equivalent. Thus, it is also correct to say 
any query language must have the expressibility of relational calculus or relational algebra. In either 
case, a language that satisfies this requirement is said to be relationally complete. 
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buzzword, it is found in advertising for products that may have little to do with the object- 
oriented paradigm. This brings to mind a quote used earlier: “I have a cat named Trash. In 
the current political climate, it would seem that if I were trying to sell him (at least to a 
Computer Scientist), I would not stress that he is gentle to humans and is self-sufficient, 
living mostly on field mice. Rather, I would argue that he is object-oriented” [Kin89, p. 23]. 
The bottom line is that the object-oriented community suffers from definition overloading. 

This lack of standardization has also been problematic in that there are no 
standard benchmarks upon which to evaluate OODBMS performance [St91c]. Portability 
between systems is poor since no single OODBMS data model exists along with a standard 
core set of operations [Ed91]. OODBMSs differ among themselves on whether they have 
a class library available and what classes are provided in the library if it exists. This puts 
the consumer in a quandary since a decision must be made based on terminology that has 
different meanings depending on who wrote it to. select from very different available 
OODBMSs that may be very costly. Since each OODBMS is so different and the computer 
software industry is so volatile, the consumer may lose all support and have to turn to 
entirely new system if the company that produced his system goes under. Clearly, if 
OODBMSs had a consistent terminology and definition, then it would be much more 
widely accepted. 

3. Relational Operations 

Companies that produce OODBMSs generally think in terms of managing objects 
and not relations with their database. Thus, there are not any commercial OODBMSs that 

support relations and relational operations^. However, an OODBMS that does support 



3. Some do support an object-SQL interface. 
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relational operations would be valuable in terms of increased compatibility and 
completeness. It has been shown that relational operations can and should be made a part 
of an object-oriented database [Fi92][Ne88][NMO90]. An OODBMS that incorporates 
these operations would benefit from increased credibility along with acceptability among 
relational database developers. 

4. Other Problems 

Other problem areas that cannot be overlooked include the inability for most 
commercial OODBMSs to interface with relational systems [St91a]. A better solution is the 
integration of both object-oriented and relational systems. However, in the absence of an 
integrated approach, some interface should be available. Finally, along with the powerful 
modeling capabilities of the object-oriented data model comes an increased difficulty in 
making changes to the database as requirements change in addition to design difficulties 
[Ed91]. 

D. A COMBINED SYSTEM 
1. Desirable Properties 

A combined relational/object-oriented system will eliminate limitations that each 
of these systems possess as a system by itself. It would allow a relationally modeled system 
to naturally model and define complex objects along with their behavior which would 
facilitate better performance in complex applications. This ability is not found in simple 
extended relational systems. Generally, they allow for the definition of complex objects but 
not for their behavior. 

Relational classes as part of a combined systems class library are needed: 
database, relation, and tuple (or record) classes. Additionally, the five fundamental 
relational algebra operations (select, project, Cartesian product, difference, and union) 
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should be a part of all OODBMSs. Credibility and standardization of combined systems 
will be enhanced as a result. 

2. Possible Approaches 

Two primary approaches to a combined relational/object-oriented system exist. 
The first is to take an existing RDBMS and extend the system to include all of the concepts 
in the object-oriented paradigm. Once this has been done, the underlying system is still 
relational so the system should still have all of the functionality of a purely relational 
system along with the advantages of the object-oriented paradigm. This would be a difficult 
and arduous task. Additionally, since the underlying system is relational, it may not be as 
efficient as an object-oriented system at managing objects. The other approach is to take an 
existing OODBMS system and construct classes and associated methods that would allow 
the OODBMS to provide relational functionality within the system. Thus, the relational 
model could be used with this system. This approach is much simpler since it requires the 
construction of three classes and their associated methods as compared with trying to 
implement aU of the complex and powerful concepts of the object-oriented paradigm. 

E. WHY THIS APPROACH 

“The relational model is a viable approach to organizing persistent objects in an 
object-oriented database” [NMO90, p. 319]. The real world consists of complex entities/ 
objects that are easily modeled with an object-oriented paradigm. A R/OODBMS exists 
with the best of both worlds; it reduces the limitations that the individual systems realize 
by themselves. Conventional applications in a R/OODBMS can be extended to include 
complex data, and new non-conventional applications may also be developed in the same 
system. 

Original work done in the development of the ROOMS paradigm [Ne88] and later 
work done with a R/OODBMS as implemented in Prograph [Fi92] is extended in this 
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thesis. ROOMS was not a full R/OODBMS since it lacked the ability to store persistent 
objects. A R/OODBMS in Prograph was a logical next step in the extension of ROOMS to 

a full database system."^ This work completes the proof of concept that began with ROOMS 
and culminates in its extension into a commercially available OODBMS, IDB. The system 
implemented in this thesis is a single R/OODBMS that can fulfill the requirements of both 
relational and object-oriented users. 



4. This is because Prograph is an object-oriented programming language that supports the storage 
and retrieval of persistent objects in secondary storage through its built-in database primitives 
[Fi92]. 



IV. IMPLEMENTATION OF AN R/OODBMS IN IDB 



An R/OODBMS in EDB, as implemented in this thesis, is the culmination of a proof 
of concept that began with ROOMS [Ne88]. In that respect, it is not intended to be a 
production/commercial system. This chapter describes the fundamental design and detail 
of the implementation of an R/OODBMS in IDB. Although, there may be ‘better’ or more 
efficient implementations, the system as described is functional and does provide a proof 
of concept. It should also be noted that the author has worked exclusively with the 
commercially available IDB system. That is, there were no special/trade tools provided by 
Persistent Data Systems for this effort. 

A. THE SYSTEM DESIGN 

As described in [Ne88], the fundamental design of ROOMS is quite simple. This 
thesis is modeled after that design. A database is comprised of a group of relations. A 
relation is comprised of a group of tuples. A tuple is comprised of a group of attributes. 
Database, relation, and tuples are all implemented as classes. Both database and relation 

classes are IDB node class types while the tuple class is a strict class type.^ Thus, tuples 
have as descendents user-defined classes that, when instantiated, become the tuples 
comprising a relation. In this manner, relations differ by the type of tuples they contain. 

While it is possible to create stand-alone applications in IDB, the R/OODBMS was 
created for use within the IDB browser. Thus, the IDB core, display, and browser interface 
were used in the implementation of the R/OODBMS. The R/OODBMS user interacts with 



1. Recall that in IDB a strict class type has one or more descendents while a node class type has no 
descendents. 
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the EDB browser to view the relations of a particular database and to perform relational 

2 

algebra operations on relations within a particular database. 

Figure 17 shows a picture of the IDB Browser Interface. Pull down menus are listed 
along the top of the window. Within the browser, the programmer/application developer 
may introduce their own menus. We opted not to use this feature; instead the commands 

that the R/OODBMS user needs are displayed in the Menus pane.^ 



Cluster Vieu Options Conna^ Context Heap Help 


Rddress Database 
Hissionaru/Cannibal Database 

Relational Rddress DB2 
















=> dbdir:dbdir CE] /Hone 
root : linked seq => [Address Database, « 
current ; linked seq => [Rddress Database,«««l 
context : nil => nil 




Wmm 

Current First 
Last 




Help: sequence elenent 

Error: 

nornal > 





Figure 17 IDB Browser Interface 



2. A database directory was developed to allow the R/OODBMS to manage more than one database. 
APPENDIX B contains the source code, the IDL schema and C implementation of the methods for 
the database directory cluster. APPENDIX C contains the IDL schema and C method implementa- 
tions for R/OODBMS. 

3. There are four panes within the browser window as shown in Figure 17: Current Object, Context 
Object, Browser State, and Menus. The user may have none, all, or any combination of these panes 
displayed at any time by making appropriate menu selections from the View menu commands. 
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Since the R/OODBMS is implemented as a proof of concept, it is not designed to have 
all of the facilities that are expected in a production system. Therefore, several assumptions 
are made about the R/OODBMS. It is assumed that the user will input correct information, 
in the correct syntax, for the R/OODBMS relational algebra operations and that the 
relations named as operands in the operation actually exist within the database. 
Additionally, all tuples within a relation must be instances of the same tuple descendent 
class. Thus, error checking is not provided consistently in all relational algebra operations. 
That is, different amounts of error checking have been provided among the operations in 
the hope of demonstrating the feasibility of detailed error checking without the overhead of 
implementing it for every operation. In two cases, detailed error checking has been 
implemented to demonstrate the feasibility of doing it for all operations, as will be 
described shortly. 

By the same token, the relational operations, as implemented in this thesis, are 
implemented in the simplest manner possible while still demonstrating the feasibility/proof 
of concept of a R/OODBMS. For example, you may recall from Chapter II that the 
selection condition of a selection operation is a boolean expression consisting of clauses of 
the form: 

<name of attributexcomparison operatorxconstant value>; 

or 

<name of attributexcomparison operatorxname of attribute> 
where <name of attribute> is the name of an attribute of the input parameter relation; 
<comparison operator> is either =, <, <, >, >, or and <constant value> is any arbitrary 
number of clauses may be connected with the AND, OR, and NOT operators to form the 
selection condition expression [EN89]. In this implementation of R/OODBMS, only one 
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clause is allowed for the selection condition since allowing an arbitrary number of clauses 
is just repeated applications of one clause in its simplest form.^ 

B. ORIENTATION TO R/OODBMS 

This section is intended to familiarize the reader with using the R/OODBMS. It is not 
intended to be a complete user’s guide. However, it should provide sufficient information 
so that a user could use the source code in APPENDIX B and APPENDIX C on a platform 
supported by IDB, translate the IDL schema, compile, and run the R/OODBMS. 

1. The Database Directory 

The database directory allows multiple R/OODBMS databases to be managed in 
IDB. If IDB is run with the following command line entry, then IDB will open the database 
directory cluster and display the browser window shown in Figure 17: ‘idb -c dbdir -t 

dbdir’.^ In Figure 17, there are four databases in the directory: Address Database, 
Missionary/Cannibal Database, Relational Address DB, and Relational Address DB2. If 
one of the databases is selected, say the Relational Address DB, then the browser window 
would appear as shown in Figure 18. Here the Relational Address DB object is the current 
object and the directory (sequence) of databases becomes the context object. To enter this 
database, select the enter command from the Menus pane. 



4. Of course, there are more efficient methods of implementation than just repeated applications. 

5. The name following the -c flag (dbdir in this case) in the command indicates the home cluster that 
will be used when IDB begins running. The name following the -t flag (dbdir) indicates the home 
cluster type. In this case, the home cluster is dbdir.c and its type is dbdir. 
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IDB Browser 


a 


Cluster Vieu Options Cohn^ Context Heap Help 


Relational Rddress DB 
type : relational 
file:rel«addr 
exaninertrue 




Rddress Database 
Hissionary/Cannibal 
Relational Rddress D 
Relational Rddress D 




=> dbdir:dbdir [E] /Hone 

root ; linked seq => [Rddress Database,***] 
current : database => Relational Rddress DB 
context : linked seq => [Rddress Database,** 




Current 
Context First 
Last 
Forward 
Backward 




Help: enter this cluster 

Error: 

nornal > 





Figure 18 Entering a Database 



2. Inside a R/OODBMS Database 

Entering the Relational Address DB database, IDB opens the database cluster and 
displays the relations within the database in the Current Object pane as shown in Figure 

19.^ Now, any of the relations can be opened. For example, if the ptl relation is selected 
then the Context Object pane will display the list of all relations within the database and the 
Current Object pane will display short form of the tuples within the relation ptl (see Figure 
20). Since each tuple within a relation is also an object, a tuple can be selected in which 



6. In the interest of saving space and enhancing readability, interesting panes only will be shown in 
Figures. 
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case the list of tuples would move to the Context Object pane and the particular tuple 
selected is displayed in the Current Object pane. 



(HI IBB Browser 



il 



Cluster View Conwands Current ConteKt Heap Help 



Relational Rddress OB 



=> rl 
r2 
r3 

test2 

TEMPI 

rd 

r5 

Ptl 

pt2 

Cart Resultl 
project resultl 
conp obj 




Help; select this nenu 

Error; 

nornal > 



Figure 19 The Relational Address DB 



Notice that as different objects are displayed in the Current and Context Object 
panes, the commands available in the Menus pane change. At any time, the Menus pane 
will display those methods associated with the objects being displayed in either of the 
object panes as long as the application programmer has specified them to be browser 
visible; there may be methods that are required by an object for interaction with other 
objects only that the application programmer decides the application user should not have 
access to (i.e., they are not browser visible). 
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IDB Brovser 
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Relational Rddress D 




=> 550926190 2 10 

999999999 1 45,200 

123456789 2 51,5 

987654321 30 4 


=> rl 

r2 
r3 

test2 

TEMPI 

r4 
















Current HeuTuple 
Union 
Projection 
Difference 
CartesianPro 
Selection 

Context NeuRelation 




Help: select this nenu 

Error: 

nornal > 





Figure 20 The Relation ptl 



When any of the relations within a database is displayed in the Current Object 
pane, the Menu pane commands associated with the Current Object include the five 
fundamental relational algebra operations that are implemented within the R/OODBMS. 
Selecting any of the relational algebra operations brings up an associated pop-up window 
that allows the particular operation to be expressed in a query. The details of each of the 
relational algebra operations are discussed in the next section. 
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C. RELATIONAL METHODS 



As discussed in Chapter II, there are five fundamental relational algebra operations 
from which all other relational algebra operations can be constructed; union, difference, 
selection, Cartesian product, and projection. These five operations are implemented as 
methods for the node class relation in the R/OODBMS. The difficulty in implementing 
these operations is directly related to the structure of the resultant relation as compared to 
that of the operand relation(s). 

With the union, difference, and selection operations, the resultant relation has the 
same structure as the operand relation(s). Thus, the resultant relation’s structure is already 
defined within the database and can be used to construct the resultant relation. In this sense, 
these operations may be considered simple. Cartesian product and projection, on the other 
hand, both yield resultant relations that have a different structure from the operand 
relation(s). Thus, the resultant relation’s structure may not already exist within the database 
and either must be explicitly defined in the schema or dynamically constructed at run-time. 
Thus, these two operations may be considered difficult. 

The details of each operation are discussed below along with difficulties encountered 
in their implementation and special implementation notes. Once one of the simple 
operations (i.e., result relation has the same structure as the operand) was completed, the 
other simple operations followed relatively quickly in their implementation. Selection, 
however, was more difficult than the other two since it required the implementation of 

n 

default comparison operations: equal to, less than, and greater than/ 



1 . As discussed in Chapter II, there are six comparison operators: =, <, >, and The last 

two are a combination of = and < and = and >, respectively. ^ is just the inverse of =. Thus, it is 
sufficient to implement only =, <, and >. 
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Before continuing, it is important to discuss the two possibilities for inserting tuples 
into the resultant relations: (1) a new tuple object can be created and then the values of the 
tuple can be copied into this new tuple, or (2) a reference to the tuple to be inserted can be 

used.^ If the first approach is used, then the relations are independent of each other. That 
is, an update to any of the relations (operand or resultant) will have no effect on the other 
relations. 

In the second approach, the relations become interdependent since they reference the 
same tuple relation. Thus, a change to the tuple in one relation will also be reflected in the 
corresponding referenced tuple in the other. This may or may not be desirable. A problem 
associated with this approach is the resolution between duplicate tuples in a binary 
operation. For example, there are two relations A and B, and we would like to perform the 
union operation. Relation A contains a tuple that is identical to one in B. Thus, it is a 
duplicate and must not be duplicated in the resultant relation, call it C. But, which tuple 
does C reference: the tuple in A or the tuple in B? They are both identical. 

It would be best to allow the user to indicate in their query which of the two 
approaches is desired for a particular query. To show the feasibility of both approaches, 
some operations in the R/OODBMS were implemented using the reference approach while 
others used the copy approach. However, no operation was implemented with both 
approaches left for the user to choose from. It is clear, however, that if they can be 
implemented separately, then it is just a matter of additional programming and fine-tuning 
the user interface to add the ability to let the user choose. 

The persistence of the resultant relation for these operations should also be 
considered. The resultant relation is not initially written to the database in secondary 



8. That is, either make a copy of attributes in existing tuples or provide pointers to them. 
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storage, although it does appear in the list of relations for the database in the browser 
window (it only exists in main memory). If a write transaction is entered and committed, 
then the resultant relation will be written to secondary storage. If a write transaction is not 
entered and subsequently committed, then the resultant relation is lost when the transaction 
on the database is closed. Additionally, if a write transaction is entered and subsequently 
aborted, then the database cluster is read from disk again and any relation not previously 

stored on secondary storage is lost.^ 

Although a resultant relation only exists in main memory, it may be used in other 
queries just as any other relation within the database. It does not matter whether the 
temporary resultant relation has been committed to secondary storage, as far as the 
relational algebra operations are concerned - the resultant relations may be operated on as 
any other relation. For example, if relation R1 were unioned with R2 and the resultant 
relation TEMP_R3 were yielded, then a subsequent difference operation could be executed 
using TEMP_R3. It should be remembered, however, that even though these relations may 
be used in other queries, they are not written to secondary storage until a write transaction 

has been entered and subsequently committed. 

We will now discuss each of the 5 basic operations individually. 

1. Union 

The union operation is performed by the function union_op. It takes two relations, 
R1 and R2, and computes their union. The resultant relation is created by the function 



9. Naturally, if a query is made during a write transaction, then the persistence of the resultant rela- 
tion depends solely upon whether the write transaction is aborted or committed. 

10. All resultant relations will be saved when the commit is executed. By the same token, if the write 
transaction is aborted then all of the resultant relations will be lost since a new transaction is entered 
after the abort which causes the database to be read from secondary storage. 
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init_temp_rel which takes R1 and R2 as its parameters and returns a relation with a unique 
name and some default values taken from Rl. The syntax of the union operation (shown in 
the center of the pop-up window within the parentheses) is shown in Figure 2L Notice that 
there is no resultant relation listed in the query. This operation creates and names a resultant 
relation that will appear in the list of relations for the current database (this is in contrast to 
the project and Cartesian product operations where the resultant relation is named in the 
query, as will be discussed shortly). As previously noted, it would be desirable, in a 
production system, to have the ability to phrase a query with the option of providing a 
relation name or having a default name generated. 
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Figure 21 Union Query 
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The union operation, in contrast to the other operations^ ^ has extensive error 
checking in its implementation. The R/OODBMS first checks to make sure that the operand 
relations exist within the database. If both relations are found in the database, then they are 
checked for union compatibility. Provided that the relations exist and are compatible, a 
temporary relation is created by the init_temp_rel function and subsequently its tuples are 
inserted, ensuring no duplicate tuples. Tuples are inserted by reference and in the case of 
inserting a duplicate tuple, a reference is made to the tuple from relation Rl. 

The function used to check for duplicate tuples is the equal_to method which is 
defined for the class tuple. As such, it has a default implementation that only checks to see 
if the tuples reference the same object. This method will most likely have an over-riding 
user-supplied implementation for each tuple type. The prototype/signature for the method 

is boolean equal_to(tuple, tuple, index) . That is, the function takes three parameters, two 
tuples and an index, and returns a boolean. Each of the tuples must be of the same type. 
When the value of the index is 0, then the equal_to function compares the each entire tuple, 
all the attribute values. Otherwise, index is greater than zero and is an index to the attribute 
within the tuples that is to be compared (selection operation). This function is also used in 
the selection operation. 

2. Difference 

The difference operation is implemented in a manner similar to that of the union 
operation. The function set_diff_op takes two relations and computes their difference. The 
resultant relation is created in exactly the same manner as in union_op. Set_diff_op also has 



11. The difference operation has the same level of error checking as the union operation. 

12. This is the actual C function signature/prototype that shows the function equal_to has three pa^ 
rameters (tuple, tuple, and index) and returns a boolean to the caller of the function. 
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the same level of error checking as union_op. The main difference between its 
implementation and that of union_op is in the insert decision for tuples that will comprise 
the resultant relation. 

In the union_op function, all of the tuples from R1 are inserted into the resultant 
relation. Afterwards, the tuples from R1 are compared with those already in the resultant 
relation and if they are not duplicates, then the tuple from R2 is inserted into the resultant 
relation. In the set_diff_op, each tuple in R1 is checked to see if it exists in R2; if it does 
not, then the tuple is inserted into the resultant relation. Insertion is by reference here as in 
the union_op function. Figure 22 shows the difference query pop-up window with the 
correct syntax for the query. 
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Figure 22 Difference Query 
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3. Selection 



Of the three simple operations, selection was the most difficult to implement. It is 
a more complex operation since, even in its simplest form, it operates on a single attribute 
of a relation (which can be any one of the attributes in the relation’s schema) and compares 
the value of that attribute for every tuple in the relation with a specified value to determine 
which tuples should be included in the resultant relation. Again, the resultant relation is 
created using the function init_temp_rel. This implementation, select_op, has the 
functionality necessary to demonstrate the feasibility of implementing a fully functional 
selection operation. 

The general syntax for the R/OODBMS selection operation is: 

<relation name> select <attribute name> <comparison operator> <attribute value> 
where <relation name> is the name of the relation to be operated on, <attribute name> is 
the name of the attribute within the relation upon which selection will be based, 
<comparison operator> is a user-defined comparison operator (equal_to, greater_than, or 
less_than), and <attribute value> is the value to be compared with. Figure 23 shows the 
select query syntax. The particular query listed selects all tuples of ptl where the attribute 
value of Hours Worked is greater than the Hours Worked attribute in Comp Object. 
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Figure 23 Select Query 



It would be desirable to be able to list just a value for the <attribute value>; 
however, at a minimum it is necessary to be able to compare the same attributes of two 
objects. In R/OODBMS, the <attribute value> is a comparison object of the same type as 
the operand relation, Rl. This comparison object can only have one tuple in it and may must 
have at least one of the attribute values entered, the one to be used for comparison. In Figure 
23, Comp Object has the same type as ptl, thus it has the same attributes. The one tuple in 
Comp Object has 20 as the value for Hours Worked. Thus, the query is equivalent to select 
all tuples in ptl where Hours Worked is greater than 20. 

Select_op checks the database to ensure that both the relation to be operated on 
and the comparison object are both in the system. If they are, then the attribute name is used 
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to determine the index into the relation schema. If either of these conditions is not met, then 
the system brings up a pop-up window explaining that an error has occurred, what the error 
is, and allows the user to continue without crashing. Again, init_temp_rel is used to create 
and name the resultant relation for this operation. Finally, based on the comparison operator 
specified in the query, the appropriate comparison method is executed. The tuples of the 
operand relation are iterated through and those meeting selection criteria are inserted into 
the resultant relation by reference. 

4. Cartesian Product 

'Of the two more difficult operations, Cartesian product is the simpler to 

1 ^ 

implement as it operates on all attributes of the tuples in each of the operand relations. 
Since the resultant relation has a different structure than either of the operand relations, the 
init_temp_rel function cannot be used. Instead, the user must provide the definition of the 
resultant relation within the database IDL schema beforehand. Now, a relation can be 
created within the database to hold the result of the operation. As a logical consequence, 
the relation that is to hold the result of the operation must be named in the query. Figure 24 
shows the Cartesian product query pop-up window with the required syntax. 



13. This is in contrast to the project operation where only a subset of the attributes will end up in the 
resultant relation. In a Cartesian product operation all of the attributes from each operand relation 
will be in the resultant relation. 
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Figure 24 Cartesian Product Query 



Defining the resultant relation’s IDL schema is not difficult since we know that 
its schema is simply the concatenation of the two operand relation’s schemas. No matter 
how complex the two operand relation’s schemas are, the Cartesian product resultant 

relation will simple include the attributes as defined in both of the operand relations. For 
example, suppose there are two relations. Employee and Assigned Project, with their 
respective tuple types defined with the IDL schema shown in Figure 25. 



14. If multiple inheritance were available, the resultant relation could simply be defined as a subclass 
of each of the operand relations. As such, it would inherit the attributes of each of superclasses. 
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emp_tuple => 


person 


person, 




address 


addr. 




phone 


phone_numbe r , 




widget 


idl_univ; 


proj_tuple => 


essn 


integer, 




proj_num 


integer. 




hours 


rational; 



Figure 25 IDL Schema for Employee and Assigned Project Relations 



In our example, the attribute types of each of the tuples in the Assigned Project 
relation are simple: integers and rational. However, in tuples in the Employee relation, 
attributes have user defined (and provided) types and are, therefore, more complex. But, it 
is still a simple matter to create the schema for the resultant relation for a Cartesian product 
operation since all of the types (person, addr, phone_number, idl_univ, integer, and 
rational) are already defined within the database IDL schema (see Figure 26). 



cartl_result_tuple => person 


person. 


address 


addr. 


phone 


phone_number , 


widget 


idl_univ. 


essn 


integer. 


proj_num 


integer. 


hours 


rational ; 



Figure 26 Example Resultant Relation Schema for a Cartesian Product Operation 



Cart_prod_op implements the Cartesian product operation by first determining if 
the two operand relations and the resultant relation are in the database. If they do exist, then 
it is a fairly simple matter to take one tuple at a time from the first operand relation, 
concatenate it with each tuple of the second, and insert each resultant tuple into the resultant 
relation. The function insert_tuples is used by cart_prod_op to insert the tuples into the 
resultant relation. 
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In the query shown in Figure 24, r3 is a relation with emp_tuple type tuples, ptl 
has proj_tuple type tuples, and Cart Result 1 has cartl_result_tuple type. Figure 27 shows 
the relation r3 with its two tuples, Kelly and Spear. In the left side of Figure 27, all of r3’s 

tuples are shown in their abbreviated form.^^ In the right side, a single tuple is shown in its 
entirety. 



i S 

: => Kelly 
: => Spear 

The Relation r3 

The Spear tuple of relation r3 
Figure 27 The Relation r3 and One of its Tuples 

The relation ptl is less complex and as such its abbreviated version has all of the 
information of each tuple. Therefore, there is no need to include a single tuple of ptl in the 
Figure 28. If a single tuple were shown, there would be three values: an employee ssn, 
project number, and hours worked. However, these values would then be listed sequentially 
in a vertical fashion. 



=> Ronald L* ■I BSW <29 Dec 62> [Karin] 
SSM: 120928190 



=> <408)375-8819 



s> 3978 Ricketts Road 
Hontereyr Cfl 

93940 



15. The abbreviated form only shows the last name of the person attribute. The predefined IDE func- 
tions idl_print and idl_key can have their implementations over-ridden by the user to present the re- 
lation and its separate tuples in any desired fashion. Figure 27 shows one such display. 
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=> 120926190 


2 


10 


999999999 


1 


45.200 


123456789 


2 


51.5 


987654321 


30 


4 



Figure 28 The Relation ptl 



The result of the Cartesian product of relations r3 and ptl is shown in Figure 29. 



The left side of the figure shows the abbreviated display of the relation Cart Result 1 tuples, 



while the other side shows one entire tuple from the relation. 






Kelly 


120926190 
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=> Spear 
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=> Ronald L. <29 Dec 62) 

SSN: 120926190 

=> (408)375-8619 

=> 3976 Ricketts Road 
Honterey^ CR 

93940 

120926190 

2 

10.0 



The Relation Cart Result 1 



The Spear tuple of Cart Result 1 



Figure 29 Cartesian Product of r3 and ptl 



5. Projection 

Although the projection operation has a resultant relation with the same number 
of tuples as the operand relation, it is complicated by the fact that any combination of the 
attributes of the operand relation can constitute the schema of the resultant relation. As with 
Cartesian product, since the resultant relation has a different structure than that of the 
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operand relation, the user must provide the definition for the resultant relation in the IDL 
schema beforehand. Again, this is not a difficult task since the schema of the resultant 
relation is a subset of the attributes of the operand relation. Thus, all of the attribute types 
must already be defined in the database schema. Parsing the query is more difficult since 
any combination of the attributes can be specified in the query to be projected into the 
resultant relation. Figure 30 shows the browser pop-up window that accepts the project 
query and also specifies the query syntax for this operation. 



IDB Brovser 



Cluster Vieu Options Connands Current Context Heap Help 



project 1 



=> 20.399 
3.2000 
67.25 









Please input the Project query <R2 = R1 project flttr.list)^ 



Help: connand input line 
Error: 

Response > 



oject Hours Horked,Enployee S5N 



3a 

ce 
nPro< 
n 

ion 



JL 

Help: 

Error: 

Projection > project 1 = ptl project Hours Morked,Enployee SSM 



Figure 30 Project Query 



Consider a relation with tuples of type proj_tuple as defined in Figure 25. If the 
user wanted to project the hours worked and employee ssn of each tuple, then a schema for 
the resultant relation would look like the one in Figure 31. The function project_op 
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implements the operation. Once it has checked to ensure that the operand relation and the 
resultant relation exist, it calls the function insert_fields to insert the appropriate attributes 
into the resultant relation. 



pro jectl_result_tuple 


=> hours : 


rational, 




essn : 


integer; 



Figure 31 Example Resultant Relation Schema for a Project Operation 



D. THE DATABASE CLASS 

The database class is an IDL node class and is actually quite simple. Its sole purpose 
is to keep track of the relations within the database. As mentioned in Chapter II, each IDB 
cluster must have a root class from which all other classes can be reached. For the R/ 
OODBMS, the database class is the root. Thus, all functions that implement the relational 
algebra operations start their search for the relations from this class. This coincides with the 
idea of a database being a collection of relations. 

1. Attributes 

The database class has only two attributes: name and relations. The name attribute 
is included so that when a database is entered users can see the name of the database that 
they are in. However, none of the operations in the R/OODBMS require this attribute. The 
relations attribute is very important since it is the means by which all relations in the 
database are reached. Its type is a sequence of relations where relation is another IDL node 

class. The sequence is a doubly-linked list.^^ All of the R/OODBMS relational algebra 
operations use the relations attribute to iterate through when trying to locate a particular 
relation within the database. 
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2. Methods 



As with all objects in R/OODBMS, the predefined IDB core interface methods 

idl_key and idl_print are over- written. Simply stated, idl_print displays an object while 
idl_key displays a short desaiption of the object [Pe91a]. Their predefined 
implementations are functional but, of course, cannot anticipate the types of objects that 
will be displayed, much less the most pleasing format to display them in. In the following 
discussion of other classes these methods will not be discussed again although each has its 
own implementation for the idl_key and idl_print methods. 

The only other method defined for the database class is new_relation which, as 
the name implies, creates a new relation and inserts it into the database. To create a new 
relation using the new_relation method, the user must first enter a write transaction. 
Otherwise, when this method is selected from the Menus pane, an initialize new relation 
pop-up window will appear but the user will not be able to view and edit all of the relation 
attributes necessary. If a write transaction is open when new_reIation is selected, then the 

1 o 

pop-up window will display all attributes of a relation ready for editing. The user is 
responsible for initializing the relation attributes to valid values. 



16. Sequences in IDB are either arrays (the default) or doubly-linked lists. Arrays are convenient for 
sequences with a static number of entries. However, every time the size of the sequences changes 
there is a great amount of overhead involved. Linked lists support sequences whose number of en- 
tries varies dynamically. 

17. Both idl_key and idl_print can only be used with the display manager. An exception will be 
raised if attempts are made to invoke these methods without the display manager. [Pe91a] 

18. The idl_print implementations for relations do not display all attributes during read and examine 
U*ansactions. However, since the user needs the ability to edit all attributes, they are visible during 
write and create transactions. 



77 



E. THE RELATION CLASS 



Codd’s relational model is simple, representing databases as a collection of relations 
(or tables). Hence, relations are the fundamental building block of the model and as such 
the relation class of our R/OODBMS is the fundamental building block of the system. As 
with the database class, the relation class is an IDB node class type. Since a relation is a 
collection of tuples, it stands to reason that the attribute tuples is the most important 
attribute in this class. 

1. Attributes 

a. Relation_name 

This attribute plays a greater roll in the R/OODBMS than does the database 
classes’ attribute name. The relation_name allows different relations within a database to 
be easily differentiated. Of course, the database name within the database directory plays 

as great a role. The type of this attribute is an IDB string.*^ 

b. Attribute_names 

The relational schema is specified by the relation’s attributes which are listed 
in attribute names. This attribute has a type that is a sequence of name where name is an 
object/class (an IDB node class) that has a single attribute, name. The name attribute of the 
name object is a string type. Thus, attribute_names is simply a sequence of strings. Since 
the schema of a relation is static, the default array sequence is used here. 



19. An IDB suing differs from a C suing in that it has an additional null character at the end of the 
string. That is, there are two null characters at the end of an IDB suing. IDB suings can generally be 
used in the same manner as C suings. 
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The degree of a relation is simply determined by the number of attributes. 
This is easily done by checking the size of the array that comprises attribute_name. Two 
relations are said to be union compatible if each is of the same degree and if corresponding 
attributes have common domains. Thus, attribute_names is used by both the union and 
difference operations to determine if the two operand relations are union compatible. 

The project and select operations are the only other R/OODBMS relational 
algebra operations that require the attribute attribute_names since they operate on a subset 
of the attributes and single attribute of the operand relation, respectively. Specifically, 
attribute_names is used to determine if an attribute(s) in a query is in the operand relation 
or not. Additionally, it is used to determine the index (position within the relational schema) 
of an attribute. 

c. Attribute_types 

Attribute_types is of the same type as attribute_names, however, it is used 
only in support of the union and difference operations to determine if operand relations are 
union compatible. As stated above, union compatible relations have corresponding 
attributes with a common domain. Having a common domain means that the attributes have 
the same types. Thus, once two relations are determined to be of the same order, their 
attribute types are checked to ensure that they have a common domain. 

d. Tuples 

The tuples attribute within a relation is a sequence of tuples where tuple is an 

90 

IDB strict class type. Thus, tuple has subclasses which are referenced by this attribute. 
Thus, IDB allows a relation to have a sequence of tuples where some of the tuples reference 



20. An attribute in IDB that has a strict class type can reference that class or any of its descendents. 
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one subclass type of the IDB strict class tuple while others reference a different subclass. 
However, if allowed in an R/OODBMS, then this sequence of tuples should not be called 
a relation, as this would allow various tuples to have a different number of attribute values 
and/or have different domains for corresponding attributes. Thus, all tuples within a 
relation must be of the same subclass of the IDB strict class tuple. 

It is the tuples attribute that allows one relation to differ from another in 
structure. All of the descendents of the IDB strict class tuple are user defined. The user may 
define a subclass of tuple to have any desired structure. For example, the user may with to 
have an employee relation and a project relation where the employee relation contains 
personal information about the employee while the project relation contains information 
about different projects that the company has worked on. A relation should be constructed 
to model each. To create each relation, the user must first define the type of tuple that will 
comprise each relation: an employee tuple and a project tuple. Now, the new_relation 
method of the database class is used to create the new relations. Each relation should be 
given a descriptive name. Only employee tuples should be inserted into the employee 
relation and project tuples into the project relation. This restriction must be enforced by a 
production system; however, our proof of concept system assumes that the user will do this. 

Since the number of tuples within a relation varies with time, the size of the 
tuple sequence is dynamic. Database updates, insertions, deletions, etc. generally 
necessitate a modification to the number of tuples within a relation. Therefore, the sequence 
of tuples that comprise the tuples attribute is a doubly-linked list which allows the sequence 
to dynamically grow and shrink at run-time. 

e. Tuple_type 

Tuple_type is of the EDB strict class type tuple. Thus, it can reference any of 
the user defuied tuples that comprise relations within the database. When a relation is 
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created, the tuple_type attribute must reference an object that is of the same type as all 
tuples within the relation. Therefore, an object should be created solely for that purpose and 
then the tuple_type attribute needs to reference it. 

As discussed in Chapter II, IDB invokes methods by the use of two different 
operations: idl_vop and idl_top. Idl_top is used to invoke a specific method implementation 
within the class hierarchy while idl_vop invokes the implementation of a method that is 
most closely defined for an object. For example, idl_print has a default implementation that 
is inherited by all classes. Consider the two tuple types employee tuple and project tuple, 

both of which have specific implementations for the idl_print method. Both of these 
classes have tuple as their superclass and tuple also has a specific implementation defined 
for idl_print. Thus, there are now four implementations for the one method, idl_print: the 
default, the strict class tuple’s, employee tuple’s and project tuple’s. Idl_top allows us to 
explicitly indicate which implementation of idl_print is invoked regardless of which object 
is being printed while idl_vop invokes the specific implementation closest in the hierarchy 
to the object that is to be printed. Thus, using idl_top, an employee tuple could be printed 
using the strict class tuple’s implementation. However, if idl_vop were instead used to 
invoke the idl_print method, then the employee tuple’s implementation would be invoked. 

Tuple_type is used in an idl_vop operation to indicate which implementation 
of a method to invoke. This is used most often within the method new_tuple (create_tuple 
is its C implementation) to invoke the correct implementation of initialize_tuple. Each 
descendent of the strict class tuple must have its own user defined and specified 
implementation for initialize_tuple. 



21. That is, along with their IDL schema definitions, both classes have redefined the implementation 
for the idl_print method. 
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f. Key 



The default key used in the R/OODBMS is to check the value of every 
attribute within a tuple. Each relation has at least one superkey: the key that is all of the 
attributes of the relation. By definition, each tuple within a relation must be unique. Since 

a tuple is comprised of all its attributes, the set of all its attributes is therefore a key.^^ When 
this implementation is over-ridden the user may use this attribute to specify some other key 
to be used when comparing tuples. 

2. Methods 

Other than the relational algebra operations, idl_key method, and idl_print 
method that have already been discussed, the IDB node class relation has two other 
methods defined: new_tuple and check_union_compatability. Their names are quite 
descriptive of their function. As mentioned earlier, create_tuple is the C implementation of 
the method new_tuple. As with all of the node class relation’s methods, new_tuple requires 
no user defined methods. However, it does invoke a user defined and provided method: 
initialize_tuple (a method of the strict class tuple). The function of 
check_union_compatability has already been discussed in the sections pertaining to the 
attributes attribute_names and attribute_types. 

F. THE TUPLE CLASS 

User defined tuples must be subclasses of the strict class type tuple. Of the three 
required classes that comprise the R/OODBMS, tuple is the only one that is not an IDB 
node type. As such, it cannot be instantiated into tuples (objects) that can be inserted into 



22. This is not to say it is the only key. There usually exists other keys that are a subset of attributes 
comprising a relation. 
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relations. Instead, the user must provide the definition for tuples that are descendents of this 
class. 

1. Attributes 

Tuple, as a strict class t}q)e, has no attributes defined for it. There are no attributes 
that are common to tuples of every relation. Thus, it makes no sense to define attributes at 
this level since they would be inherited by all descendents. 

2. Methods 

Each method defined for this class has a default implementation that is very 
general. As a whole, most of the default implementations are so general that they tend not 
to be very useful. Users must provide their own implementation for each method defined 
for this class. Clearly, the implementation of the method initialize_tuple must be different 
for an employee tuple than for a project tuple since they likely have different orders and 
differing domains corresponding to their attributes. 

a. Initiaiize_tuple 

As the name implies, the function of this method is to return a newly created 
and initialized tuple. It has a tuple as its only parameter, creates a new tuple, initializes the 
tuple with valid values, and returns the new tuple. 

b. Insert fields and Insert tuples 

The first approach attempted in implementing these insert_fields and 
insert_tuples, which support the project operation and Cartesian product operation 
respectively, was unsuccessful. Consider the Cartesian product operation: to form the 
resultant relation each tuple of the first operand relation is concatenated with each tuple in 
the second. This concatenation process is continued for every tuple in the first relation. It 
therefore seemed logical to create a function called insert_tuple that would take as its 
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parameters two operands, the tuple to be inserted and the resultant tuple. Each user defined 
tuple used within a relation in the database would have their own particular implementation 
of the method. 

For example, recall the tuple types defined by the schemas in Figure 25 and 
Figure 26. To insert the resultant tuples into the resultant relation for the operation Cart 
Resultl = r3 X ptl (where the relation Cart Resultl has tuples of type cartl_result_tuple, 
relation r3 has type emp_tuple, and ptl has type proj_tuple), the relation r3 would be 
iterated through a tuple at a time. The insert_tuple method for r3 would then be invoked to 
insert the r3 tuple values into the resultant relation tuple. Subsequently, insert_tuple would 
be invoked again however, this time for ptl which would insert its tuple’s values into the 
resultant relation tuple. Thus, one complete tuple of the resultant relation is complete. This 
would continue with the first tuple in r3 and every tuple in ptl. Subsequently, the same 
process would be done for the rest of r3’s tuples. 

It is clear that the resultant tuple, sent as a parameter to the insert_tuple 
method, will always have correct attributes to have values filled in; however, it will also 
have other attributes that will change from one invocation to the next Additionally, the 
tuple to be entered into the resultant tuple will always be a constant type belonging to the 
class for which the particular insert_tuple implementation is specified. That is, the 
insert_tuple implementation for emp_tuple will always have a parameter tuple that is of 
type emp_tuple, with attributes person, address, phone, and widget, to be inserted into the 
resultant tuple. The resultant tuple parameter sent to this implementation of insert_tuple 
will always have attributes person, address, phone, and widget in addition to the attributes 
essn, proj_num, and hours. 

Now the same operation is executed again except with ptl replaced by a 
relation called R2 that has the attributes sponsor_ssn and dependent_name. An appropriate 
resultant tuple type, cart2_result_tuple, is created with the attributes person, address. 
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phone, widget, sponsor_ssn, and dependent_name. This time when insert_tuple is invoked 
for r3 it will receive two tuples: one of type emp_tuple and the other of type 
cart2_result_tuple. Again the resultant relation has the attributes that this implementation 
will requires, person, address, phone, and widget, but this time the resultant tuple also has 
the attributes sponsor_ssn and dependent_name. Thus, each implementation of insert_tuple 
must be able to handle differing structures for the resultant relation. This proved to be 
problematic for both the insert_tuple method and insert_field method. 

The solution used in our R/OODBMS is to have two methods called 
insert_tuples and insert_fields. Instead of having every tuple type that belongs to some 
relation in the database, each resultant tuple type requires its own implementation. That is, 
in our example involving the Cartesian product operation, cartl_result_tuple and 
cart2_result_tuple would both have their own implementation of the method. There are 
now three parameters to the method: the two operand relations and the resultant relation. 
The entire concatenation process is completed within these methods and the resultant 
relation is returned from the method after completion. The method insert_fields works in a 
similar manner; however, it requires only two parameters, the operand relation and 
resultant relation. 

c. Comparison methods 

The comparison methods implemented in the R/OODBMS are equal_to, 
less_than, and greater_than. The equal_to method is used by the check union compatibility 
function and select operation. Although there are default implementations for these within 
the R/OODBMS, they have very limited applicability since the possible tuple types are 
limitless and each generally requires specific implementation for comparing tuples of the 
same type. Thus, the default implementations are a point of departure, but users must 
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provide their own implementations for each tuple type that is user defined if the R/ 
OODBMS is to perform properly. 

The designer of the comparison operator methods has many decisions to 
make regarding their implementation. If the tuple type is complex with attributes that have 
a type that is a user defined object, then deciding at which level comparisons will be made 
may be difficult. For example, in Figure 25 the schema for an emp_tuple class is shown. 
An instance of this class has four attributes: person, address, phone, and widget. Each of 
these attributes is a user provided/defined class. Figure 32 shows the definition for these 

classes (except for widget ). Which level do the comparison operators compare at? When 
the person attribute of an emp_tuple is compared with another, are the object IDs (OIDs) 
of the objects that they reference compared? Or is every attribute of the person object: 
fname, mname, Iname, ... compared? Or maybe the comparison should be made at a more 
detailed level? 



person => fname 


string. 


mname 


string, 


Iname 


string. 


bdate 


string. 


ssn 


integer, 


spouse 


string. 


sptr 


person_nil ; 


addr => street 


string. 


city 


string. 


state 


string, 


zip 


string; 


phone_number => number ; 


: string; 



Figure 32 Person, Addr, Phone_number Class Definitions 



23. The attribute widget is an arbitrarily complex attribute that has yet to be defined by the user. 
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As the attributes of a relation become more complex, it is easy to see how 
many variations there are for implementations of comparison operator methods. By the 
same token, it is also easy to see that one default implementation could never hope to be 
functional for more than just the simplest of attributes. Without user provided 
implementations for the comparison operator methods, user defined tuple types in R/ 
OODBMS will not work properly. 

3, User Definitions 

The relations that can be formed within R/OODBMS are limited only by what the 
user can define within an IDL schema. However, it is critical that specific implementations 
for methods inherited from the IDB strict class tuple be written for all user defined tuple 
types. The implementation of the relational algebra operations for the IDB node class 
relation depend on them. 
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V. ALTERNATIVE PROJECT AND CARTESIAN PRODUCT 
IMPLEMENTATIONS 



A. GENERAL 

Of the five fundamental relational algebra operations (union, difference, select, 
Cartesian product, and project), Cartesian product and project are considered to be the most 
difficult. As discussed in Chapter IV, this is because the resultant relation yielded by these 
two operations have a different structure from the operand relation(s). For this reason, both 
ROOMS [Ne88] and our R/OODBMS require that the resultant relation structure for these 
two operations be defined by the user prior to the execution of the operation. This chapter 
deals with an IDB specific alternative solution to this approach. 

Recall that an attribute that has a type that is of an IDB strict class type can reference 
any object that is a descendent of that strict class type. Thus, an attribute that is of type tuple 
can reference any object that is an instantiation of an IDB node class type which is a 
descendent of class tuple. In both ROOMS and R/OODBMS, the user is required to provide 
the definition of the resultant tuple. In Chapter IV, the only two resultant relation tuple 
types for Cartesian product and project operations that are defined are cartl_result_tuple 
and project l_result_tuple respectively. Hence, any result of either of these two operations 
(in the database as defined in the schema of APPENDIX C) must have the structure of 
cartl_result_tuple and project l_result_tuple. That is, the Cartesian product operation can 
only be executed on two relations where the first relation has tuples of type emp_tuple and 
the second relation has tuples of type proj_tuple. Similarly, the project operation can only 
project the hours and essn attributes of relations that have type proj_tuple. 

Say that you wanted to perform a project operation on a relation with tuples of type 
proj_tuple for the attributes proj_num and hours. Or, that you wanted to take the Cartesian 
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product of a relation with proj_tuple types and another with emp_tuple types. In both cases, 
new tuple subclasses for the resultant relations would have to be defined prior to run-time. 
However, there is an alternative in IDB: the use of the type ‘any’. 

B. IDB TYPES 

An attribute in an DDL schema can have any of the types listed in Figure 33. A R/ 
OODBMS relation has an attribute called tuples that has type sequence of tuple where tuple 
is a IDB strict class type. Thus, any subclasses of tuple may be referenced by the class 
relation’s attribute tuples. Therefore, a relation’s schema is defined by the stmcture (tuple 
subclass definitions) of its tuples. In our R/OODBMS, the user must provide these subclass 
definitions to define their relations. In other words, the subclasses of class tuple are all user- 
defined classes. For example, in Chapter IV two tuple subclasses were used: emp_tuple and 
proj_tuple. Consider an Employee relation, it would have tuples that are of type emp_tuple. 
Our R/OODBMS relation’s attribute tuples would then reference a sequence of 

emp_tuple.^ 

Another way to gain the same effect as having the relation’s attribute tuples reference 
a different tuple subclass differing Cartesian product and project queries is to define one 
subclass that has the flexibility to dynamically reference varying number of tuple attributes 
and differing types of attributes with each instantiation. A tuple can be thought of as a 
sequence of attribute values, so if a linked list is used to allow the flexibility required in the 
sequence size then we simply need a type (this equates to the domain of an attribute) that 
can reference any object within the database. That is, each attribute in the resultant relation 



1. It is important to note that emp_tuple and all other subclasses of tuple must be IDB node class 
types. That is, node class types may be instantiated into objects whereas strict class types cannot 
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could have any domain that is already defined in the database. Any attribute that is of type 
‘any’ can reference any object within the database. 



reference 


string 


sequence 


array 


linked 


class 


any 


user-defined 


nil 


embedded 


primitive 


boolean 


integer 


rational 



Figure 33 IDL Types^ [Pe9 Ic, p. 62) 



C. THE RESULT TUPLE SUBCLASS 

In this alternative implementation, only one resultant relation tuple type is needed. It 
has been called result_tuple and has one attribute, values, which has type sequence of any 

(see Figure 34 and APPENDIX E^). Thus, this attribute can reference any object within the 
database. Since we cannot anticipate how many attributes any particular resultant relation 
will have, the sequence of any is a linked list of any which allows the number of attributes 
(values) within a result_tuple to vary from one result_tuple to another. Hence, this one tuple 
type can be used as the resultant tuple type for any operation in R/OODBMS. 



2. The difference between reference and embedded types is important to note. Attributes that are ref- 
erence types are pointers to an independent object that contains the attribute value. In contrast, at- 
tributes that are embedded types have their value imbedded within the object that it beIongs.[Pe9lc] 

3. Changes from the original R/OODBMS schema (APPENDIX C) are in bold in APPENDIX E. 
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result_tuple 



=> values 



: seq of any; 



Figure 34 Resultant Relation Schema for Project and Cartesian Product 

Both the modified project operation and the modified Cartesian product operation 
create the resultant relation using a function that initializes all of the class relation attributes 
to initial values before the tuples are inserted into the relation. In both cases, the relation 
attribute tuples is initialized to reference an empty linked list of type result_tuple. A pointer 
to the new resultant relation is passed back to the calling function so that the tuples can be 
inserted into the relation. This initialization function differs for the two operations and will 
be discussed in further detail in the sections below. Each of these initialization functions 
(init_proj_result_rel and init_Cart_result_rel) is a variation of the init_temp_rel used by the 
simple operations (union, difference, and select). 

D. THE MODIFIED OPERATIONS 

1. Project 

There are a number of functions used by the modified project operation that also 
required modification. These functions along with the modified project operation, 
project_op are listed in APPENDIX E. Note that these are only the functions from the 
original R/OODBMS shown in APPENDIX C. In order to have a working R/OODBMS 
with this alternative approach, the functions in APPENDIX E must be inserted into the code 
in APPENDIX C. Functions in the two appendices that have the same name indicate that 
the newer modified function replace the identically named function in APPENDIX C. All 
other functions in APPENDIX E that have unique names should simply be inserted. 
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The project query syntax is changed to that shown in Figure 35. The project_op 
function still implements the project operation. The difference between this 
implementation and the original begins with a modified function that parses the project 
query: Project_parse_action. There are fewer tokens to parse than in the original 
implementation. 
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Figure 35 Modified Project Query 



An additional data structure is required by this implementation since there is a 
need to pass an array of indexes as a parameter to the insert_fields_b function. This 
structure, index_array, is defined in the EDL schema in APPENDIX E; however, since it is 

not reachable from the root, it can never be written to the database.^ Index_array has one 
attribute that is a sequence of integers that are used to indicate which attributes will be 
projected. 



4. Remember that for an object to be written to secondary storage in IDB it must be reachable from 
the root. 
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Insert_fields_b is the workhorse of the function project_op. This modified 
function requires an additional parameter, index_array, that was not required by 
insert_fields. Otherwise, it still accepts two other parameters: the operand relation and 
resultant relation. The user must provide certain methods that override inherited methods 
during the construction of their relations. For example, the user must provide overriding 
implementation for the comparison operators for each relation. In the same vein, the user 
must provide an overriding implementation for the insert_fields_b method that they all 
inherit. The reason for this is that each relation has a different list of attributes that may be 
projected; thus one generic field (attribute) insertion method wiU not suffice. In the 
modified R/OODBMS schema only emp_tuple had an overriding implementation 
provided. Thus, project operations may only be done on relations with tuples that are of 
type emp_tuple type. The resultant relation from a project operation of a relation with 
proj_tuple types would yield meaningless results since no overriding implementation for 
insert_fields_b is provided in the schema. 

Each user provided overriding implementation can be a copy of 
insert_emp_fields_b with a few modifications. Each attribute must have its own case that 
inserts that particular attribute into the resultant relation tuple (its index is in index_array). 
In Figure 36, insert_emp_fields_b has been modified to indicate the portions of the function 
that need to be changed for each relation within the database. Note that a new object is not 
created for each attribute that is inserted into the resultant relation; instead each attribute of 
the operand relation that is to be projected is referenced by the resultant relation tuple. This 
issue of creating an independent object for the resultant relation’s attributes versus simply 
referencing the attributes of the operand relation(s) was discussed in Chapter IV and 
therefore it will not be discussed again here. 

It should be noted that in this implementation the resultant relation from a project 
operation cannot itself be used as the operand relation for another project operation. This 
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could be done but would require a general overriding implementation of the insert_fields_b 
method that would not conform to the template shown in Figure 36. The fundamental 
difference between all user provided tuple subclass definitions and the result_tuple 
definition is that the user provided subclasses all have no attributes that are of a sequence 
types while the only attribute of the result_tuple is a sequence type. This difference will 
require that the attribute values are inserted into the resultant relation by use of 
idl_linked_for which wUl iterate through each of the attributes within the operand relation’s 
tuples to find the appropriate attributes to insert. This is in contrast to using a case statement 
to insert the appropriate attributes. 

The insert_fields_b method returns the resultant relation to project_op with all of 
the correct tuples inserted. Finally, the function project_op inserts the pointer to the new 
resultant relation into the sequence of relations that make up the database. Again, the 
resultant relation is not written to secondary storage until a transaction is opened that allows 
writing and is subsequently committed. 
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idl_routine relational_relation insert_XXXX_f ields_b ( rel, result_rel, index_array) 
relational_relation rel, result__rel; 
relational_index_array index_array; 

{ 

idl_transaction tr = idl_get_trans(rel); 
relational_result:_tuple new_tuple; 

result_rel->tuples = idl_empty_linked( cr , relational_tuple) ; 

idl_linked_for ( relational_tuple, rel->tuples, rel_tuple) 

{ 

/* iterate through each tuple and for each tuple iterate through 

the index_array and use a case statement to reference objects for 
fields to be entered into the result relation */ 

new_tuple = idl_new ( tr , relat ional_result_tuple) ; 
new_tuple->values = idl_empty_linked( tr, relat ional_any) ; 

idl_linked_for ( relat ional_index, index_array->indexes, index) 

{ 

switch (index->i) 
case 1 ; 

idl_insert_back( relational_any, new_tuple->values, rel_tuple->attr 1 ) ; 
break; 
case 2: 

idl_insert_back( relat ional_any, new_tuple->values, rel_tuple->attr 2) ; 
break; 
case 3: 

idl_insert_back( relatibnal_any, new_tuple->values , rel_tuple->attr 3) ; 
break; 



case n; 

idl_insert_back ( relat ional_any, new_tuple->values, rel_tuple->attr II) ; 
break; 

default : 

idl_raise ( IDL_ERROR, 

"There is a problem in the employee insert field b 

function ! " ) ; 

break ; 

} 

} idl_end_for 

idl_insert_back( relat ional_tuple, result_rel->tuples , new_tuple) ; 

} idl_end_for 



Figure 36 Template for Overriding Insert_fields_b Method 



2. CARTESIAN PRODUCT 

The discussion in the previous section regarding modified function’s insertion 
into APPENDIX C also applies to those modified functions listed in APPENDIX F for 
Cartesian product The Cartesian product query syntax is changed to that as shown in 
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Figure 37. The function cart_prod_op implements the Cartesian product operation. As with 
the project operation, the new query syntax dictates that there are fewer tokens to parse. As 
such, the function Cartesian_parse_action has been modified to parse this new query 
syntax. 
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Figure 37 Modified Cartesian Product Query 



The workhorse of the function cart_prod_op is the method insert_tuples_b- 
Insert_tuples_b still takes the same number and type of parameters as the original 
insert_tuples. In contrast to the insert_fields_b of the project operation, the insert_tuples_b 
method as defined for the class tuple does not require a user provided overriding 
implementation for each relation. Instead, the method insert_tuples_b is general enough 
that overriding implementations are not needed. The function does not need to worry about 
how many attributes each operand relation has. It simply iterates through every tuple in the 
first operand relation and concatenates the one tuple at a time with each tuple of the second 
operand relation (see code in APPENDIX F). 
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However, if the alternative approach to inserting tuples into the result relation is 
taken, then the user would have to provide an overriding implementation of insert_tuples_b 
for each relation as he must do for the insert_fields_b method of the project operation. The 
reason for this is that after an object has been created to hold the tuple to be entered into the 
resultant relation, the appropriate values must be explicitly copied into the newly created 
object. Once this has been done, then the new object with the tuples attribute values can be 
inserted into the resultant relation’s tuple. 

Since, with this implementation of insert_tuples_b. there is no need for any other 
redefinition of the method, the resultant relation yielded from a Cartesian product operation 
may be used as one of the operand relations in a subsequent Cartesian product query. As 
stated earlier, this is not possible with the project operation. 

E. CONCLUSIONS 

This alternative implementation of project and Cartesian product appears to be very 
promising. The project operation functions in the manner expected from a relational 
database perspective. That is, if you want to project attribute 3, attribute 5, and attribute 1 
of a particular relation, then the resultant relation will have those three attributes only and 
they will be in that particular order. If you project attribute 5, attribute 3, and attribute 1, 
then the resultant relation will have three attributes that correspond to these three but in the 
order specified in the query. Similarly, Cartesian product yields the resultant relation that 
is expected. 

There is one additional area that must be discussed, the displaying of the resultant 
relation. The approach taken in our R/OODBMS implementation was to provide a specific 
overriding implementation of the idl_print and idl_key methods for all relations. However, 
when the resultant relation is displayed in this implementation, the system defined 
implementations of idl_print and idl_key are used since a general overriding 
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implementation cannot be written for the resultant relation as each resultant relation may 
differ in structure. This makes it somewhat difficult to view the tuples of the resultant 
relation. However, this can easily be overcome as demonstrated in Nelson’s 
implementation of ROOMS [Ne88] by having a display (overriding implementation of 
idLprint and idl_key in this implementation) implementation for every object in the 
database. That is, if an attribute of a relation is itself an object, then that object would have 
a specific implementation of the idl_print and idl_key methods. 
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VI. CONCLUSION 



The purpose of this research was to implement a combined relational/object-oriented 
database management system, R/OODBMS, that will overcome the deficiencies/ 
constraints of separate relational and object-oriented systems. This thesis expands previous 
work in this area that showed basic proof of concept by implementing relational operations 
in an object-oriented programming language which did not provide for persistent objects 
[Ne88][NMO90], and by implementing relational operations in an object-oriented 
programming language which does provide for persistent objects [Fi92]. A R/OODBMS as 
implemented in EDB, a commercially-available object-oriented database management 
system, demonstrates the extension of previous work to a commercially-available object- 
oriented database management system. 

A. SUMMARY 

A detailed literature review investigating object-oriented programming concepts, 
relational database management systems, object-oriented database management systems 
(including a detailed overview of IDB), and a brief discussion of previous work in the area 
was accomplished. Limitations of conventional relational database management systems 
and object-oriented database management systems were explored while identifying 
desirable properties of a combined approach. 

The R/OODBMS, as described in Chapter IV, is specific to an implementation of 
ROOMS [Ne88][NMO90] in IDB. However, as with previous work in this area, this 
research demonstrates the validity of the ROOMS concept and further , completes and 
strengthens the proof of concept started by Nelson [Ne88]. 
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B. CONCLUSIONS 



A combination of relational and object-oriented database management systems, a R/ 
OODBMS is a logical and viable solution in overcoming each individual system’s 
limitations providing the best of both worlds within a single system. In a R/OODBMS, the 
relational paradigm gains the ability to model and manage arbitrarily complex data that 
traditional RDBMS are unable to handle. Additionally, the object-oriented paradigm gains 
the acceptance, standardization, and firm theoretical foundation that traditional RDBMSs 
enjoy. Thus, a single system can satisfy the requirements of users of both traditional 
systems and overcome many of their individual limitations. 

C. FUTURE RESEARCH SUGGESTIONS 

Future research in this area should generally be focused on the development of a 
production system. The methods used to implement the five fundamental relational algebra 
operations could be rewritten with efficiency and optimization in mind. During the 
implementation of the R/OODBMS in IDB as presented in this thesis, neither efficiency nor 
optimization were of great importance. Instead, the focus was on constructing an 
implementation that was functional. 

In constructing queries, the user of our R/OODBMS does not have the option of 
naming the resultant relation for those operations (union, difference, and select) that create 
the resultant relation. The R/OODBMS creates a default name and assigns it to the resultant 
relation. A production system should allow the user the option to provide a name for the 
resultant relation if desired or to accept the default name provided by the system. For 
example, a query of the form ‘R1 union R2’ would indicate that the user is willing to accept 
the default name that the system provides. However, a query of the form ‘R3 = R1 union 
R2’ would indicate that the user would like the relations R1 and R2 to be unioned together 
and the result relation to be name R3. 
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There are several issues that will remain as design decisions for a production system. 
One issue involves how objects of the same class are compared with one another. Are two 
objects equal if they both reference the same OID? Or, should every attribute of the objects 
be compared to determine if each corresponding attribute has the same value for each 
object? A similar problem arises with the inequality comparison operators. When is one 
object greater than another? Even for complex objects that have attributes which are simple, 
this issue becomes difficult. 

For example, consider an employee of a company that has a first name, middle name, 
last name, phone number, and street address. When the relation is defined within the R/ 
OODBMS, the relation could be called Employee and have tuples of type employee_tuple. 
An employee_tuple might have three attributes defined: full_name, phone_number, and 
address where full_name and address are objects and phone_number is an integer (a local 
phone number without area code). The object full_name has attributes first_name, 
middle_name, and last_name where each attribute is a string. Address has attributes street, 
city, state, and zip_code where street, city and state are strings and zip_code is an integer. 
Now, consider the equal comparison operator. If we are trying to compare two employee 
tuples from two different relations, it is easy to determine if the phone_number in one tuple 
is equal to that of another. The value is simple an integer that may be compared directly. 
However, what if it is desirable to compare the full_name attribute? Realizing that it is itself 
an object, do we move to that object and consider each of its attributes (first_name, 
middle_name and last_name) as a whole? Do we compare OlDs? Or, do we allow a single 
attribute of full_name to be compared, such as only last_name? Or, do we allow any 
combination of the attributes to be compared for equality? This example can be generalized 
for any of the comparison operators whether they are equality or inequality comparison 
operators. 
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The issue of comparison operator implementation is also of concern in the set 
operations union and difference during the determination of union compatibility and the 
determination of whether a tuple is a duplicate of another tuple within a relation. This issue 
is also present in the select operation where attributes of different tuples are compared 
during as part of the selection criteria. 

The assumption was made during this implementation of a R/OODBMS that the user 
made no errors. Therefore, limited error checking was built into the system. A production 
system would require extensive error checking for all of the relational algebra operations. 

Another issue is found in the insertion of tuples into resultant relations. Our R7 
OODBMS uses two methods of insertion: by reference or by creation. That is, the tuples of 
the resultant relation may have new tuples created and then the values that the tuple is to 
have are copied into the attributes of the tuple. Alternatively, the tuples of a resultant 
relation can simply be a reference to the tuple that contains the values to be inserted. 

In this second approach, two (or more) different relations can refer to the same tuple. 
Thus, a change to the tuple in either relation is reflected in the other relation. This approach 
is problematic since if there is a duplicate tuple in two relations that are being unioned 
together, the resultant relation will only reference one of the two. Now, a change to the 
tuple in the resultant relation will be reflected in only one of the two operand relations. This 
is not very consistent and requires that the user be aware of how the system determines 
which tuple is going to be referenced in the resultant relation. If the first approach is used, 
the problem is alleviated since every tuple in the resultant relation is independent of every 
tuple in any of the operand relations. 

Finally, the project operation in a production system should allow the user to rename 
the attributes being projected into the resultant relation. However, the issue of attributes 
that are complex objects comes to light again. In our employee example, if a project 
operation were used to project all the names of employees and to change the name of the 
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attribute in the resultant relation, is the user only allowed to change the attribute full_name 
to some other name? Or, is the user allowed to change each of the attribute names (such as 
first_name, middle_name, and last_name)7 Or, is the user allowed to change any one or 
more of these attribute names? 

Additionally, our R/OODBMS requires the user to form a select query using the 
syntax ‘R1 select <attribute name> <comparison operator> <comparison object>’ where 
the comparison object has the same superclass as R1 and has only a single tuple. A 
production system should also allow the user to construct a select query of the syntax ‘R1 
select <attribute name> <comparison operator> <value>’ where value is the display form 
<attribute name>. For example, in our employee example, the user should be allowed to 
enter the query ‘R1 select phone_number = 3758619’. 
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APPENDIX A: EXAMPLE IDL SCHEMA 



structure vhc root diet is 

diet => local : 

remote : 

fleet => vehicles : 

vehicle ::= train I plane; 

vehicle => location : 

destination : 

vehicle -> move {*, city , city ) 



fleet , 

cross of fleet; 
seq of vehicle; 

city, 

city_nil; 



city => 
city_nil 



name : string; 
city I nil; 



train : : = 
train => 
car => 
ptrain =>; 



ptrain I ftrain; 

cars 

number 

ftrain =>; 



seq of car; 
integer; 



plane : : = 
plane => 

pplane =>; 
passenger ::= 
passenger => 

freight : : = 
freight => 
person => 



pplane 1 f plane; 
airborne 
f plane =>; 
ptrain 1 pplane; 
max 

passengers 
ftrain 1 fplane; 
cargo_weight 
name 



boolean; 



integer , 
seq of person; 

rational; 

string; 



for fleet . vehicles use linked; 
for train. cars use linked; 
for passenger .max use unsigned; 
for passenger .max use bytes{2); 



for vehicle. idl_print use bind (vehicle_print ) ; 
for train. idl_print use bind (train_print ) ; 
for vehicle. move use bind (vehicle_move) ; 



for vehicle . location use search; 

for vehicle. location use search_embed; 

for ptrain use description ( "passenger train"); 

for ftrain use description ( "freight train"); 

for pplane use description ( "plane (passenger)"); 

for fplane use description ( "air freight"); 

for passenger .max use 

description { "maximum number of passengers"); 

end 

process vhep is vhc ::= vhea : access; end 
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APPENDIX B: DATABASE DIRECTORY SOURCE CODE 




-- dbdir.idl 

Schema for database directory 
-- Description: 

A directory cluster is used to group together other clusters into 
a directory. In this directory, the clusters are databases. 



★**********★*****★★***★***★***********★*******★******■■*■■*■■*■■*■***■■*■*★*•**■*★**■*★**** 



for database . dbname use description ( "database structure name" ) ; 

for database . fi le use description ( "database cluster file name"); 

for database . desc use description ( "description of the database cluster"); 

for database . examine use descript ion ( "enter in ‘examine mode?"); 

for database , desc use search; 

database -> enter (*, boolean) => boolean; 

for database . enter use browser_cond_visible ; 

for database . enter use descript ion ( "enter this cluster"); 

for database . idl_key use bind (dbdir_key ) ; 
for database . idl_print use bind {dbdir_print ) ; 
for database . idl_create use bind(dbdir_icreate) ; 
for database . enter use bind (dbdir_enter) ; 

end 

process dbdirp is 

dbdir ::= dbdi ra : access; 



structure dbdir root seq of database is 



for root use linked; 



database => dbname : string, 



database name 
database file name 
description of database cluster 
default initial transaction 



file : string, 
desc : string, 
examine : boolean; 



end 
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^★★★★★★★★****--***************'********************** 



*★★*•******•*•*•**★*★**•**★***★ 



* dbdir.c 



* Description: 

* 

* This module provides the operations for IDB database directories. 

* This module is considered to be part of the IDB browser. It invokes 

* internal browser routines to enter and exit database clusters. 



★ ★★******'*r*********************'***-***‘*****-******-*****************-**-*********-* 



#include 

#include 

#include 

#include 

#include 

#include 

#include 



"stdio . h" 
"idlrt .h" 
"dbdira . h" 
"dpy . h" 
"brwa . h" 
"brw . h" 
"brwi . h" 



static char buff [100]; 



y**************************-****-*'*-***'-*****************-*'***-********-******-*'****** 
★ 

* OPERATIONS 

* 

* _brw_dbdi r_key ( * ) 

* _brw_dbdir_print { * , mode) 

* _brw_dbdi r_ic reate ( tr) => * 

* _brw_dbdi r_en ter {*/ boolean) => boolean 

* 



idl_routine void _brw_dbdir_key (db) 
dbdir_database db; 

{ 

^py_cstring (db->desc) ; 

) 



— print short form db description 
-- print full display 
-- create database object 
-- enter cluster 
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idl_routine void _brw_dbdir_print (db, mode) 
dbdir_database db; 
dpy_dmode mode; 

{ 

if (mode. expand > 0) 

{ 

idl_top (idl_any, idl_print, (db^mode) ) ; 
return; 

} 

dpy_open ( " " , false) ; 

dpy_attr (dbdir_database, db, desc,mode) ; 
if ( idl_get_display (dbdir_database, dbname) ) 

{ 

dpy^eol ( ) ; 

dpy_cstring ( " type : " ) ; 

dpy_attr (dbdir_database, db, dbname , mode) ; 

} 

if ( idl_get_display (dbdir_database, file) ) 

( 

dpy_eol ( ) ; 

dpy_cstring ( " file ;"); 

dpy_attr (dbdir_database, db, file, mode) ; 

} 

if ( idl_get_di splay (dbdir_database, examine) ) 
{ 

dpy_eol ( ) ; 

dpy_cstring ( "examine : " ) ; 

dpy_attr (dbdir_database, db, examine , mode) 

} 

dpy_close ( ) ; 
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static dbdir_dat abase new_db; 

idl_routine void _brw_dbdir_dact ion (check) 
integer check; 

{ 

_idl_not_used (duminy ) ; 
if (check == 1) 

{ 

integer fd; 

string full_name = _brw_map_db (new_db->dbname ) ; 
if (idl_string_size (new_db->dbname) == 0) 

{ 

dpy_error ( "no database name specified"); 
return; 

} 

(void) sprintf (buf f , "%s . bst" , full_name) ; 
if (fd > 0) 

{ 

(void) close (fd); 

} 

else 

{ 

(void) sprintf (buff , "unable to find symbol table file %s.bst", 
full_name) ; 
dpy_error (buf f ) ; 
return; 

) 

if (idl_string_size (new_db->f ile) == 0) 

{ 

dpy_error ( "no structure name specified"); 
return; 

) 

if (idl_string_size (new_db->desc) == 0) 

{ 

new_db'>desc = new_db->file; 
dpy_error ( "defaulting description") ; 
return; 

) 

} 

dpy_qui t ( ) ; 

} 

idl_routine void _b rw_dbdir_s screen (a, x,y) 
integer a, x,y; 

{ 

dpy_dmode mode; 

_idl_not_used (a) ; 

mode = dpy_dmode_default; 

dpy_open( "Define New Database" , true) ; 

dpy_open ( "New Database" , true) ; 

brw_cmd ( "Check" , "check and exit if correct" , _brw_dbdir_dact ion, IL, BRW_SCREEN) 
dpy_spacex ( 5L ) ; 

brw_cmd ( "Nocheck" , "exit without checking" ,_brw_dbdir_daction, OL, BRW_SCREEN) ; 

dpy_eol { ) ; 

dpy_spacey (2L) ; 

dpy_eol ( ) ; 

mode. expand = 1; 

idl_vop (new__db,dbdir_database, idl_print , (new__db,mode) ) ; 
dpy_close ( ) ; 

brw_input_area (y-3 , false) ; 

dpy_close ( ) ; 
dpy_boxed ( x , y ) ; 
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idl_routine dbdir_database _brw_dbdir_icreate ( tr) 
idl_transaction tr; 

{ 

string empty = idl_copy_string ( tr , " " ) ; 
new_db = idl_new (tr,dbdir_dat abase ) ; 
new_db->dbname = empty; 
new_db->file = empty; 
new_db->desc = empty; 
new_db->examine = true; 
dpy_active (_brw_dbdir_s screen, OL) ; 
return new_db; 



idl_routine boolean _brw_dbdi r_en ter (db, test ) 
dbdir_database db; 
boolean test; 

{ 

if (i test) 

{ 

integer tkind = BRW_READ; 

idl_if (brw_tr,_brw_dict->curr_tr, btr) 

( 

(void) sprintf (buf f , "%s/%s" , btr->name, db->desc) 

} 

idl_else 

{ 

(void), sprintf (buff, " **uiik:nown* */%s" , db->desc) ; 
} idl_end_if 

/* open new transaction */ 
if (db->examine) tkind = BRW_EXAMINE; 

(void) _brw_topen ( idl_copy_st ring (brw_static, buf f ) , 
db->dbname, db->f ile, 

OL, 

BRW_NORMAL, tkind, true) ; 

} 

return true; 

) 



idl_def ine_ops dbdir_opbind ( ) 

{ 

idl_bind_root (dbdir) ; 
idl_bind ( "dbdir_key " , _brw_dbdir_key ) ; 
idl_bind( "dbdir_print " ,_brw_dbdi reprint) ; 
idl_bind( "dbdir_icreate" ,_brw_dbdir_icreate) ; 
idl_bind( "dbdir_enter" ,_brw_dbdir_enter) ; 
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APPENDIX C: R/OODBMS SOURCE CODE 



Contents 

IDL SCHEMA Ill 

Database Schema Ill 

Relation Schema 1 1 1 

Tuple Schema 112 

Tuple Subclasses 1 12 

Employee Tuple Schema 113 

Project Tuple Schema 1 14 

Cartesianl Result Tuple Schema 114 

Projectl Result Tuple Schema 114 

R/OODBMS FUNCTIONS 116 

Class Database Methods 118 

Class Relation Methods 122 

Union Method 131 

Difference Method 135 

Cartesian Product Method 140 

Project Method 145 

Select Method 152 

Class Tuple Methods 155 

Class Emp_Tuple Methods 158 

Class Proj_tuple Methods 167 

Class Cartl_Result_Tuple Methods 170 

Class Projectl_Result_Tuple Methods 173 

no 



//////////////////////z / ///// ////////////////////////////////// ///,'//// ///////// 

IDL SCHEMA 

//////////////////////////////////////////////////////////////////////////////// 



--Title 
--File name 
--Associated 
files 
--Author 
--Date 


A Relational/Object-Oriented Database Management System 
relational . idl 

relational. c relationala . h relational . bst relational . so 
Ronald L. Spear 
24 September 1992 
Master's Thesis 


--Advisor 

--Second 

Reader 

--System 

--Compiler 

--Translator 

--Description 


Maj Mike Nelson 
Prof. Thomas Wu 

Sun 4/60 Workstation, Unix Operating System 
AT&T C 

IDL vl.l, Persistent Data Systems 

This file contains the IDL schema for the implementation of 
A Relational/Object-Oriented Database Management System. 



structure relational root database is 

*★★***★***★***★*****★**★**★★********★**★★*★**★*★★★★***★★*******************★★* 

//////////////////////////////////////////////////////////////////////////////// 

Database Schema 

//////////////////////////////////////////////////////////////////////////////// 



database => 


name : string, 

relations : seq of relation; 


database -> 


new_relation ( * ) ; 



//////////////////////////////////////////////////////////////////////////////// 

Relation Schema 

//////////////////////////////////////////////////////////////////////////////// 



relation => 


relation_name : string, 

attribute_names : seq of name, 

attribute_types : seq of name, 

tuples : seq of tuple, 

tuple_type : tuple, 

key : string; 


relation -> 


new_tuple { ^ ) , 

check_union_compatability (relation, relation) => boolean; 


relation -> 


union ( * ) , 
projection! * ) / 
difference ( *) , 
Cartesian_product ( * ) , 
selection ( ^ ) ; 


name => 


name : string; 
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//////////////////////////////////////////////////////////////////////////////// 

Tuple Schema 

//////////////////////////////////////////////////////////////////////////////// 



tuple -> 



equal_to( tuple, tuple, integer) 
less_than (tuple, tuple, integer) 
greater_than ( tuple, tuple, integer) 



=> boolean, 
=> boolean, 
=> boolean. 



ini tialize_tuple (tuple) => tuple, 

insert_fields (relation, relation) => relation, 

insert_tuples (relation, relation, relation) => relation; 



//////////////////////////////////////////////////////////////////////////////// 

Tuple Subclasses 

//////////////////////////////////////////////////////////////////////////////// 



tuple ::= emp_tuple I 

proj_tuple I 
cartl_resul t_tuple I 
pro jectl_result_tuple I 
nil ; 



_****★*★★*★★********★★************************★****★*★★**★***★★★★★*★***★★****★★ 



for database .new_relation use browse r_vi si ble; 

for relation . new_tuple use browser_visible ; 

for relation . union use browser_visible; 

for relation . Cartesian_product use browser_visible; 

for relation . difference use browse r_vi si ble; 

for relation .pro jection use browse r_vi si ble; 

for relation . selection use browser_visible; 



for database . relations use linked; 
for relation . tuples use linked; 



__******************** Database, Relation, and Tuple Methods 






for database . idl_key use bind(database_key) ; 
for database . idl_print use bind(database_print) ; 
for database . new_relation use bind (create_relation) ; 

for relation . idl_key use bind(relation_key) ; 
for relation . idl_print use bind ( relation_print ) ; 
for relation .new_tuple use bind(create_tuple) ; 

for relation . check_union_compatability use bind(ck_union_compatabili ty ) ; 

for relation .union use bind (union_op) ; 

for relation .Cartesian_product use bind(cart_prod_op) ; 

for relation. difference use bind (set_dif f_op ) ; 

for relation. projection use bind (pro ject_op) ; 

for relation .selection use bind(select_op) ; 

for name.idl_key use bind(name_key) ; 
for name . idl_print use bind (name_print ) ; 

for tuple . equal_to use bind(equal_to) ; 

for tuple . less_than use bind (less_than) ; 

for tuple .greater_than use bind (greater_than) ; 

for tuple . ini tialize_tuple use bind( ini tialize_tuple) / 
for tuple . insert_fields use bind (insert_f ields) ; 
for tuple . insert_tuples use bind (insert_tuples ) ; 
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******-*r*'t***-*r****************'t**'*r**** 0fnp tUP 1 0**********'***'*’****^********'*’**** 



//////////////////////////////////////////////////////////////////////////////// 

Employee Tuple Schema 

//////////////////////////////////////////////////////////////////////////////// 



emp_tuple => 


person 

address 

phone 

widget 


person, 

addr, 

phone_number 

idl_univ; 


person => 


f name 
mname 
Iname 
bdate 
ssn 

spouse 

sptr 


string, 

string, 

string, 

string, 

integer, 

string, 

person_nil ; 


person_nil : : 


= person I nil; 


addr => 


street 

city 

state 

zip 


string, 

string, 

string, 

string; 


phone_n umber => 


number 


; string; 



■k-k-k-k-kie-kie-k'k-k-kieic-k-kieieieieic-kieie-k-k-xieic'kic-k-kicic 0jy|p tUplG JY|0j2j^Q^2************************** 

for emp^tuple . idl_key use bind (emp_ tup lG__key) ; 

for Gmp_tuple . idl_print use bind (emp_tuplG_print ) ; 

for emp_tuple . equal_to use bind(emp_equal_to) ; 

for emp_tuple . less_than use bind (emp_less_than) ; 

for emp_tuple. greater_than use bind (emp_greater_than) ; 

for emp_tuple. initialize_tuple use bind ( init iali ze_emp_tuple) ; 

for person . idl_key use bind (person_key ) ; 
for person . idl_print use bind (person_print ) ; 

for addr.idl_key use bind (addr_key ) ; 
for addr . idl_print use bind (addr_print ) ; 

for phone_number . idl^print use bind (phone_number_print ) ; 
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**■*:********★★*****★*★■**★****★***★** 



p ro j tiup]_0***^**************************** 



//////////////////////////////////////////////////////////////////////////////// 

Project Tuple Schema 

//////////////////////////////////////////////////////////////////////////////// 



proj_tuple => essn : integer, 

proj_num : integer, 
hours : rational; 

*********************************pj-Qj tuple mehods* *************************** 

for proj_tuple . idl_key use bind (pro j_tuple_key ) ; 

for proj_tuple . idl_print use bind (proj_tuple_print ) ; 

for proj_tuple . equal_to use bind (pro j_equal__to ) ; 

for proj_tuple . less__than use bind (pro j_less__than) ; 

for proj_tuple . greater_than use bind (pro j_greater_than) ; 

for proj_tuple . ini tialize_tuple use bind (initialize_proj_tuple) ; 

********************************* r 1 1 resu 1 1 tup I0*************************** 

//////////////////////////////////////////////////////////////////////////////// 

Cartesianl Result Tuple Schema 

//////////////////////////////////////////////////////////////////////////////// 



cartl_result_tuple => person • : person, 

address : addr, 

phone : phone_number , 

widget : idl_univ, 

essn : integer} 

proj_num : integer, 

hours : rational; 

*****************************00^^^-]^ result tuple pQ0rhods****** ** *************** 

for cart l_result_tuple . idl_key use bind (cart l_result_tuple_key ) ; 
for cartl_resul t_tuple . idl_print use bind (cartl_result_tuple_print ) ; 
for cartl_result_tuple . ini tialize_tuple use 

bind ( initial ize_cartl_resul_tuple) ; 

for cart l__result_tuple . insert_tuples use bind ( insert_cartl_resul t_tuples) ; 

****************************************************************************** 



//////////////////////////////////////////////////////////////////////////////// 

Projectl Result Tuple Schema 

//////////////////////////////////////////////////////////////////////////////// 



projectl_resul t_tuple => hours : rational, 

essn : integer; 

***************************pj-Qj0Q^^ result tuple me thods ********************** 

for projectl_result_tuple . idl_key use bind (projectl_result_tuple_key ) ; 
for projectl_result_tuple. idl_print use bind (projectl_result_tuple_print ) ; 
for projectl_result_tuple . initialize_tuple use 

bind ( ini tialize_proj ectl_resul_tuple) ; 

for projectl_result_tuple . insert_f ields use bind (insert_projectl_result_f Ids) ; 
****************************************************************************** 



end 
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— ***★★★★****★*★★★★*★*★★★**★★*****★★★*★■*•★★***•★★★★*■*★*★**•★*★****■*•★★★*★*★★★★*★★★** 



process relationalp is 

relational : := relationala : access ; 

end 
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*********************************************************************************** 

R/OODBMS FUNCTIONS 

**★★★*★★★★*★★★★**•*:*★*******★******:«?★★★★**★■*•*****■*•***********★****★*******★****** 



Title 


A Relational /Object-Oriented Database Management System 


File name 


relational . c 


Author 


Ronald L. Spear 


Date 


24 September 1992 
Master's Thesis 


Advisor 

Second 


Maj Mike Nelson 


Reader 


Prof . Thomas Wu 


System 


Sun 4/60 Workstation, Unix Operating System 


Compiler 


AT&T C 


Translator 


IDL vl.l. Persistent Data Systems 


Description 


The functions in this file run with the IDB Object Database 
system version 1.1. The file containing the schema for these 
methods is relai tonal . idl . The relational . idl file was 
translated using the IDL translator and produced the 
relationala . h header file which is included for use with 




this file. 



#include 

#include 

#include 

#include 

#include 



<string . h> 
"idlrt.h" 
"relationala . h" 
"dpy .h" 

"brw .h" 



^***************************************************************************** 

* 

* Macros defined for Class person 

* 

*★*******★********★*★*★*****■****★******★**************★**★★******★******★•*:★★* y 



#define exists (v) idl_string_size ( v) != 0 

#define rexists (node, attr ) (idl_get_display ( relat ional^person, attr) && \ 
(node->attr 1= 0 && \ 
exists (node->attr) ) ) 

^define dexis ts (node, attr ) (mode . expand >011 rexists (node, attr) ) 

#define prexists (node, attr) ( idl_get_display ( relational_person, attr ) && \ 
(node->attr 1 = 0 ) ) 

#define pdexists (node, attr) (mode. expand > 0 ||\ 
prexists (node, attr) ) 
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y***************************************************************************** 

★ 

* For^vard References for all functions other than _print and _k;ey 

★ 

*•******■*★**★★*******★**★******★*★***★★★*★***★**★**★*****★★**★■*■********★**★*** ! 



idl_routine void init_rel_screen ( ) ; 

idl_routine void create_relation ( ) ; 

idl_routine void init_act ion ( ) ; 

idl_routine void init_tuple_screen ( ) ; 

idl_routine void create_tuple ( ) ; 

idl_routine boolean ck_union_compatability ( ) ; 

idl_routine void exit_act ion ( ) ; 

idl_routine void char_screen ( ) ; 

idl_routine void integer_screen ( ) ; 

static void union_parse_act ion ( ) ; 

idl_routine relat ional_relation ini t_temp_rel ( ) / 

void report_union_error ( ) ; 

static void dif ference_parse_action ( ) ; 

void report_dif ference_error ( ) ; 

static void Cartesian_parse_action ( ) ; 

void report__Cart_product_error ( ) ; 

static void Project_parse_action ( ) ; 

void report_pro ject_error ( ) ; 

static void Select_parse_act ion ( ) ; 

void report_select_error { ) ; 

idl_routine void union_op ( ) ; 

idl_routine void cart_prod_op ( ) ; 

idl_routine void set_di f f_op ( ) ; 

idl_routine void pro j ect_op ( ) ; 

idl_routine void select_op(); 

idl_routine boolean equal_to(); 

idl_routine boolean less_than(); 

idl_routine boolean greater_than ( ) ; 

idl_routine boolean emp_equal_to ( ) ; 

idl_routine boolean emp_less_than ( ) ; 

idl_routine boolean emp_greater_than ( ) ; 

idl_routine boolean pro j_equal_to ( ) ; 

idl_routine boolean pro j_less_than ( ) ; 

idl_routine boolean pro j_greater_than ( ) ; 

idl_routine relat ional_relation insert_f ields ( ) ; 

idl_routine relat ional_relation insert_tuples ( ) ; 

idl_routine relat ional_tuple initialize_emp_tuple { ) ; 

idl_routine relat ional_tuple initialize_tuple ( ) ; 

idl_routine relational_tuple ini tialize_pro j_tuple ( ) ; 

idl_routine relat ional_tuple ini t iali ze_cartl_resul_tuple ( ) ; 

idl_routine relational_relation insert_cartl_result_tuples ( ) ; 

idl_routine relat ional_tuple initialize_pro jectl_resul_tuple ( ) ; 

idl_routine relat ional_relation insert_projectl_result_f Ids { ) ; 
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^'★★★★★★★★★★★★★★★★★★★★★**************'<r**************-Jr'Jr**************-<r********-*-* 



* Class database methods 

★ 

* database_key 

* database_print 

* create_relation 

* ★****★*•★**★**★★★★■*’★*★■*•★★'*■*'*■★*★★★★★■*■****'*■★•*■■*■*■*■•*■***★*★★***★★★*•*■****•*■**'*■*★★★★** j 

Class Database Methods 



/* displays a short description of a database object */ 

idl_routine void database_key (database) 
relational_database database; 

{ 

idl_univ u; 

if (idl_3tring_size (database->name) == 0 ) 

{ 

dpy_cstring ( " ** Unnamed Database **"); 

) 

else 

{ 

u = idl_to ( idl_univ, database->name) ; 
idl_vop (u , idl_univ, idl_key , (u ) ) ; 

) 

} 



/ 



/ 



/* diplays a database object */ 

idl_routine void database_print (database, mode) 
relational_database database; 
dpy_dmode mode; 

( 

idl_transaction tr = idl_get_trans (database) ; 
boolean can_write = idl_trans_wri te_count ( t r) > 0; 
dpy_dmode model; 

model = mode; 
model. embed = 1; 

if (can_write) 

{ 

model . expand = 1 ; 
mode. expand =1; 

} 

if (model . expand > 1) 

{ 

idl_top ( idl_any , idl_print , (database , mode) ) ; 

} 

dpy_attr ( relational_database, database , name, mode) ; 
dpy_eol ( ) ; 
dpy_spacey (2L) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_dat abase, database, relations , model ) ; 
dpy_eol ( ) ; 



/*=========================================================================*/ 
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static relational_relation ini t_relation; /* global ptr to new rel to 

be initialized */ 

/* this function provides the user a pop-up screen in the browser from which 
he may edit/initialize the values of a new relation. It is called by 
create_relation. */ 

idl_routine void init_rel_screen (a, x,y) 
integer a,x,y; 

{ 

dpy_dmode mode; 

mode = dpy_dmode_default; 

dpy_open ( " Ini tiali ze New Relation",true); 

dpy_open ( "New Relation" , true) ; 

brw_cmd ( "EXIT" / "exit initialization screen" , ini t_act ion, OL, BRW_SCREEN) ; 
dpy_eo 1 ( ) ; 
dpy_spacey (2L) ; 
dpy_eol 0 ; 

mode. expand = 1; /* forces the display of all attributes */ 

/* execute the print method for the database class/type */ 

idl_vop ( init_relation, relational_database, idl_print, (ini t_relation, mode) ) ; 

dpy_close ( ) ; 

brw_input_area (y-3 , false) ; 

dpy_close ( ) ; 
dpy_boxed (x,y ) ; 
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/* Create Relation creates a new relation within a database.*/ 

idl_routine void create_relation (database) 
relational_database database; 

{ 

relational_relation new_relation; 
idl_transaction tr = idl_get_trans (database ) ; 
string empty = idl_copy_string ( tr , " " ) ; 
boolean is_writable = ( idl_trans_write_count ( tr ) > 0) ; 

new_relation = idl_new ( tr , relat ional_relation ) ; /* must still assign 

legal values, which is 
done below. */ 

new_relation->relation_name = empty; 

/* this is only done to make attribute names valid. An array with a different 
size can be created while in the browser and new_relation->att ribute_names 
can be switched to reference it if a larger array is needed. */ 

new_relation->attribute_names = idl_new_array (tr, relational_name, 1) ; 
new_relation->attribute_names [0 ] = idl_new ( tr , relational_name) ; 
new__relation->attribute_names [0 ] ->name = empty; 

new_relation->attribute_types = idl_new_array ( t r, relational_name, 0 ) ; 
new_relation->tuples = idl_empty_linked ( tr, relational_tuple) ; 
new_relat ion->tuple_type = NULL; 
new_relation->key = empty; 

/* set global pointer to new relation so that the attributes of the new 
relation may be initialized by the user. Note: that dpy_active does 
not allow other parameters to be passed, thus a global pointer is used 
so that init_rel_screen can access the new relation */ 

ini t_relation = new_relat ion; 
dpy_active ( init_rel_screen, OL) ; 

/* if a write transaction is open, then add the new relation to the database */ 
if ( is_writable) 

idl_insert_back ( relational_relation, database->relations, new_relation) ; 
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* 

* Class relation methods 

★ 

* relation_key 

* relation_print 

* create_tuple 

* c)c_union_compatabili ty 

* 

* union_op 

* cart_prod_op 

* set_diff_op 

* project_op 

* select_op 

* 

***★★★★★*★*****★*★**★*****★★**★★★****★★****★**■*★*******•*■*•*★**★**■*'*****★**★★■*■* ! 
********************************************************************************* 

Class Relation Methods 

*★★★*★★*★★★★★*★★*★★**★***★★★*★*★*★***★*★***★************★*★★★*★★***★★★★★*★*★**★★ 



/* Displays a short description of a relation "*■/ 

idl_routine void relation_key ( relation) 
relational_relation relation; 

{ 

idl_univ u; 

if (idl_string_size (relation->relation_name) == 0) 

{ 

dpy_cstring ( " ** Unnamed Relation **"); 

} 

else 

{ 

u = idl__to(idl_univ,relation->relation__name); 
idl_vop (u, idl_univ, idl_key, (u) ) ; 

} 

} 

/*==========================================================================*/ 
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/* Displays a relation */ 



idl_routine void relation_print ( relation, mode) 
relational_relation relation; 
dpy_dmode mode; 

{ 

idl_transaction tr = idl_get_trans ( relation) ; 
boolean can_write = idl_trans_wri te_count ( tr) > 0; 
dpy_dmode model; 

model = mode; 
model . embed = 1 ; 

if (can_write) 

{ 

model . expand = 1 ; 
mode . expand = 1 ; 



if (model . expand >1) 

{ 

idl^top ( idl^any , idl_print , ( relation, mode) ) ; 

} 

dpy_attr ( relational_relation, relation, relation_name,mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( 2L) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, tuples, model ) ; 
dpy_eol ( ) ; . 

if (can_write) /* Don't want to display all of these attributes unless 

there is a transaction open which allows writing to the 
database. This information is needed for the implementation 
of the R/OODBMS but is not 'needed by the user. However, 
these attributes must be assigned appropriate values if 
the relational algebra operations of the system are to 
function properly. */ 

{ 

dpy_spacey (2L) ; 
dpy_eol { ) ; 

dpy_attr ( relational_relation, relation, attribute_names , model ) ; 
dpy_eol ( ) ; 
dpy_spacey ( 2L) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, attribute_types , model ) ; 
dpy_eol ( ) ; 
dpy_spacey (2L) ; 
dpy^eol ( ) ; 

dpy_attr ( relational_relation, relation, t up le_type, model ) ; 
dpy_eol ( ) ; 
dpy_spacey (2L) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_relation, relation, key , model ) ; 

} 

) 

/*==========================================================================*/ 
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static relational_tuple init_tuple; /* ptr to new tuple to be initialized */ 

/* Init action allows ini t_xxxxx_ac tion functions to exit if EXIT is selected 
in the pop up screen for initialization */ 

idl_routine void ini traction (val ) 
boolean val; 

( 

dpy_quit 0 ; 



/* ini t_tuple_screen called by create_tuple . It allows the user to initialize 
the attributes of a new tuple. */ 

idl_routine void init_tuple_screen (a, x,y ) 
integer a,x,y; 

{ 

dpy_diRode mode ; 

mode = dpy_dmode_default; 

dpy_open (" Initialize New Tuple" , true) ; 

dpy_open ( "New Tuple" , true) ; 

brw_cmd ( "EXIT" , "exit initialization screen" , ini t__act ion, OL, BRW__SCREEN) ; 
dpy_eol { ) ; 
dpy_spacey (2L) ; 
dpy_eol ( ) ; 

mode. expand = 1; /* forces all attributes to be displayed */ 

/* executes print method for relation class/type */ 

idl_vop ( init_tuple, relational_relation, idl_print , ( ini t_tuple, mode) ) ; 
dpy_close ( ) ; 

brw_input_area (y-3 , false } ; 

dpy_close ( ) ; 
dpy_boxed ( x , y ) ; 
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/* create_tuple creates and inserts a new tuple into a relation. It calls 

tuple method ini tialize_tuple for the tuple type of the current relation. 
Each subclass of tuple must have a redefinition of the class tuple's 
method ini tialize_tuple . If there is no redefinition, then the function 
initialize_tuple is called and causes an IDL error to be raised. */ 

idl_routine void create_tuple ( relation) 
relational_relation relation; 

{ 

relational_tuple new_tuple; 

idl_transaction tr = idl_get_trans { relation) ; 

string empty = idl_copy_string ( tr , " " ) ; 

boolean is_writable = ( idl_trans_write_count ( tr ) > 0) ; 

new_tuple = idl_vop ( relation->tuple_type , relational_tuple , initialize_tuple, 

( relation->tuple_type) ) ; 

/* uses global ptr to new tuple so it can be initialized in function 
init_tuple_screen */ 

init_tuple = new_tuple; 
dpy_act ive ( init_tuple_screen, OL) ; 

/* check to see if a write transaction is open before inserting the new 
tuple into the relation. If there is not one open, then the new tuple 
is lost */ 
if ( is_writable) 

idl_insert_back (relational_tuple , re la tion-> tuples , new_tuple ) ; 

} 



/* 



*/ 
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/* ck;_union_compatabili ty takes two relations and determines if they are union 
compatible. This means that the two relations have the same number 
of attributes and that the corresponding attribute types are the same - 
in the same order. That is, they are the of the same order and 
Rl_attr(i) = R2__attr(i) for 1 less than or equal to i and i less 
than or equal to n. */ 

idl_routine boolean ck_union_compatabil i ty (ptr_Rl , ptr_R2 ) 
relational_relation ptr_Rl , ptr_R2 ; 

{ 

boolean same_order, types_equal ; 

idl_transaction tr; 

integer Rl_degree , R2_degree , i , Rl_types , R2_types ; 

tr = idl_get_trans (ptr_Rl ) ; 

types_equal = true; 

Rl_degree = idl_array_size (ptr_Rl->attribute_names) ; 

R2_degree = idl_array_size (ptr_R2->attribute_names) ; 

Rl^types = idl_array__size (ptr_Rl->attribute_types) ; 

R2_types = idl_array_size (ptr_R2->attribute_types) ; 



/* check to make sure attribute types have legal values */ 
if ( (Rl_types == 0) && (R2_types == 0)) 
idl_raise (IDL_ERROR, 

"Both R1 and R2 have illegal values for their attribute_types 

attributes ! " ) ; 
else 
{ 

if (Rl_types == 0) 
idl_raise ( IDL_ERROR, 

"R1 has an illegal value for its attribute_types attribute!"); 



} 



if (R2_types == 0) 
idl_raise ( IDL_ERROR, 

"R2 has an illegal value for its attribute_types attribute! 



) ; 



/* check to make sure attribute names have legal values */ 
if ( (Rl_degree == 0) && (R2_degree == 0)) 
idl_raise (IDL_ERROR, 

"Both R1 and R2 have illegal values \nfor their attribute_names 

attributes I " ) ; 
else 
{ 

if (Rl_degree == 0) 
idl_raise ( IDL_ERROR, 

"R1 has an illegal value for \nits attribute_names attribute!"); 



if 



} 



(R2_degree == 0) 
idl_raise (IDL_ERROR, 

"R2 has an illegal value for \nits attribute_names attribute! 



) ; 



/* check the order of each relation */ 
same_order = (Rl_degree == R2_degree) ; 

/* each attribute must be of some type. Thus, there must be the same number of 
of elements in the attribute_names array as there are in the attribute_types 
array. */ 

if ( (Rl_degree != Rl_types) && (R2_degree != R2_t.ypes)) 
idl_raise (IDL_ERROR, 

"Neither R1 and R2 have the a one-to-one correspondenceXnbetween the 
number of attributes and types listed in their\nattribute_names and 
attribute_types attibutes I " ) ; 

else 
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{ 

if (Rl_degree != Rl_types) 
idl^raise (IDL_ERROR, 

"R1 does not have a one-to-one correspondenceXnbetween its 
nattribute_names and attribute__types at tibutes ! "^ ) ; 

if (R2_degree != R2_types) 
idl_raise (IDL_ERROR, 

"R2 does not have a one-to-one correspondenceXnbetween its 
nattribute_names and at tribute_types attibutes ! "' ) ; 

} 

if (same_order) 

{ 

/* check the corresponding types of each */ 
for (i = 0; i < R2_degree; ++i) 

{ 

types_equal = ( (strcmp (ptr_Rl->attribute_types [i ] ->name, 

ptr_R2 ->attribute_types [ i 1 ->name) ) == 0); 

if ( ! types_equal ) 
break; 

} 

) 

if (same_order && types_equal) 

{ . 

return true; /* the two relations are union compatable */ 

} 

else 

{ 

if { ! same_order) 

idl_raise {IDL_ERROR, 

"The. two relations are not union compatible ! XnThey are not of 

the same order."); 
else 

idl_rai se ( IDL_ERROR , 

"The two relations are not union compatible ! XnThey do not have 
equal corresponding types."); 

return false; 

} 

) 

/*==========================================================================*/ 
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char *R1,*R2,*R3; /* global ptrs to the parameters for the union operation. 

R1 union R2 */ 

/* union_pars enaction is called by the brw_input operation within the union_op 
function. Union parse action takes the query string and parses it into the 
two operand relations R1 and R2 . */ 

static void union_parse_act ion (query ) 
char* query; 

{ 

char *Rl_ptr, *char_ptr; 
integer size, i ; 
boolean done = false; 

char_ptr = query; 

/* allocate room for parse of the union op parameters 
R1 will hold the first parameter and R2 the second */ 
size = strlen (query ) ; 

R1 = (char* ) calloc ( (size+1) , sizeof (char) ) ; 

R2 = (char* ) calloc ( (size+1) , sizeof (char) ) ; 

Rl_ptr = Rl; 
char_ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' union ' could not be 
found */ 

while (!done && size > 0) 

{ 

if (*char_ptr \= ' ')/* it not a space copy the char into Rl */ 

{ 

*Rl_ptr=*char_ptr ; 

++char_ptr; 

++Rl_ptr; 

- - s i z e ; 

) 

else /* we may have hit the delimeter for the first parameter */ 

{ 

/* check to see if next char is a "u" - the first letter of union 
which is the delimeter between the two parameters */ 
if ( strncmp (char_ptr , " union ",7) == 0) /* then it is union sentinal */ 
{ 

for (i =0; i < 7;++i) /* jump past the delimeter */ 

{ 

++char_ptr; 

--size; 

} 

strcpy (R2 , char_ptr) ; /* copy second parameter into R2 */ 
done=true; 

} 

else /* the space is part of the first parameter, so put in Rl */ 

{ 

/* space is part of first relation name so keep it */ 
*Rl_ptr=*char_ptr; 

++char_ptr ; 

++Rl_ptr; 

--size; 

} 



} 



) 



if (size != 0) /* size only = 0 if union was not found in the query */ 
NULL; 
else 

idl_rai se ( IDL_ERROR , 

"There is an error in your union query! Try Again."); 
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/* ini t_terop_rel is called by union_op, set_diff_op and select_op since they 
are the three simple relational algebra operations that have a resultant 
relation that is of the same structure as the operand relations. Init temp 
rel creates a new relation that is to be the resultant relation of one of 
the three listed operations. It assigns default values and then passes a 
reference to the new relation to the caller. */ 

idl_routine relational_relation ini t_temp_rel (pt r_Rl , ptr_R2 ) 
relational_relation ptr_Rl , ptr_R2 ; 

{ 

relational_relation temp_relation; 
static integer temp_rel_num = 0; 
idl_transaction tr; 
string temp_rel_name; 
char temp_name [ 80 ] ; 
integer degree = 0,i; 

tr = idl_get_trans (ptr_Rl ) ; 

degree = idl_array_size (ptr_Rl->attribute_names ) ; 

temp_relation = idl_new ( tr , relational_relat ion) ; /* must still assign 

legal values */ 

/* set up a unique name for resultant relation */ 
sprintf (temp_name, " %ldTEMP_%c%c . %c%c" , 

+ + 1 empire l_num , 
ptr_Rl->relation_name [0 ] , 
ptr_Rl->relation_name [ 1 ] , 
ptr_R2->relation__name [0 ] , 
ptr_R2->relation__name[l]) ; 
temp_rel__name = idl_copy_string(tr/temp_name); 

temp_relation->relation_name = temp_rel_name; 

temp_relation->attribute_names = idl_new_array ( tr, rel at ional_name, degree) ; 

/* assign default values for attribute names to be the same as those in 
R1 relation */ 
for ( i=0; i<degree; ++i) 

{ 

temp_relation->attribute_names [ i ] = ptr_Rl->attribute_names [i ] ; 

} 

temp_relation->attribute_types = pt r_Rl->at tribute_types ; 

temp_relation->tuples = idl_empty_linked( tr , relational_tuple) ; 

/* assign a default tuple type that is the same as the first relations */ 
temp_relation->tuple_type = ptr_Rl->tuple_type; 

/* default key is the key of relation R1 */ 
temp_relation->key = ptr_Rl->key; 

return temp_relation; 

} 
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/* report_union_error reports errors as the name implies. It was taken out 
of union_op and made into a separate function to make union_op more 
readable. This has also been done with the other four operations in 
the R/OODBMS. V 

void report_union_error ( f oundl , f ound2 ) 
boolean f oundl , found2 ; 

{ 

if ( ! foundl ScSc lfound2) 

{ 

idl_raise { IDL_ERROR/ 

"Neither relation is in this database!"); 

} 

else 

{ 

if (! foundl) 

{ 

idl_raise {IDL_ERROR, 

"R1 (the first parameter) is not in this database!"); 

} 

if ( ! found2 ) 

{ 

idl_raise {IDL_ERROR, 

"R2 (the second parameter) is not in this database!"); 

} 

} 

if (foundl && found2) 

{ 

idl_raise(I DL_E RROR , 

"A SERIOUS ERROR HAS OCCURED IN THE UNION OPERATION!"); 

} 
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/* union_op is executed when Union is selected within the browser. The 
syntax for the operation allows the user to input the two relations 
to be unioned and then creates the resultant relation (with an assigned 
default name) . It calls union_parse_action , ini t_temp__rel , 
check_union_compatability and report_union_error . */ 
*★*•*★*•*★***★**★★*★★★*★★******★*★★★★**★★*★*★*★****★*****★★******★★*★*★**★****★*★ 

Union Method 

**★*•*★★*★★★*********★***********★**********************★★******★*********★*★★*★ 



idl_routine void union_op ( relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , ptr_R2 , temp_relation ; 
relational_database database; 
idl_t rans_mode tmode; 
idl_univ root; 

string parameterl , parameter2 ; /* references to the parameters R1 and R2 */ 

static integer temp_rel_num = 0, index = 0; 
idl_t ransaction tr; 

boolean foundl , found2 , is_wri table = false , duplicate = true, compatible = false 

tr = idl_get_trans ( relation) ; 

tmode = idl_trans_mode_defaul t ; 

root = idl_trans_get_root ( tr) ; 

database = idl_to { relational_database, root ) ; 

foundl = false; 

found2 = false; 

is_writable = { idl_trans_wri te_count ( tr ) > 0); 

brw_input ( "Union Query", 

"Please input the union query (R1 union R2) : ", 

OL, OL, OL, false, 
union_parse_action) ; 



/* copy the C strings R1 and R2 into IDL strings */ 
parameterl = idl_copy_string ( tr , R1 ) ; 
parameter2 = idl_copy_s tring ( tr , R2 ) ; 



/* search the database for the two relations: R1 and R2 */ 
idl_linked_for ( relational_relation,database->relations, rel ) 

{ 

if (strcmp (rel->relation_name, parameterl ) == 0) /* found relation 1 */ 
{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 

} 



if (strcmp (rel->relation_name, parameter2 ) == 0) /* found relation 2 */ 
{ 

ptr_R2 = rel; 
found2 = true; 

} 

) idl_end_for 



if (foundl Sc& found2) 

{ 

/* check for union compatabil ity */ 

compatible = idl_vop (pt r_Rl , relational_relation, check_union_compatabili ty 

(ptr_Rl , ptr_R2 ) ) ; 

if (compatible) 

( 

temp_relation = init_temp_rel (ptr_Rl , pt r_R2 ) ; 

/* insert the tuples from R1 and R2 into Temp relation. First 
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all the tuples from R1 are inserted into Temp relation. */ 

idl_lin)ced_for (relat ional_tuple, ptr_Rl -> tuples, tuple) 

{ 

idl_insert_bac)c (relational_tuple, temp_relation->tuples , tuple) ; 

} idl_end_for 

/* don't insert any duplicate tuples into the resultant relation. 
Thus, have to check the tuple key with each tuple already in the 
result (or in Rl) before entering another tuple into the 
resultant relation */ 

idl_linked_for (relational_tuple, ptr_R2 ->tuples , r2_tuple) 

{ 

idl_linked_for (relational_tuple, ptr_Rl-> tuples , rl_tuple) 

{ 



/* duplicate check takes the two tuples and 

determines if they have the same attribute values. If yes, 
then they are duplicates. It returns a boolean. */ 

duplicate = idl_vop (rl_tuple, relational_tuple, equal_to, 

( rl_tuple, r2_tuple, index)); 



if (duplicate) 

{ 

break; 

/* get out of loop cuz found tuple was a duplicate */ 

} 

} idl_end_for 



if (Iduplicate) 

{ 

idl_insert_back ( relational_tuple, 

temp_relation->tuples , r2_tuple) ; 



} 

} idl_end_for 



/* If a write transaction is open when this command is executed then 
if it becomes committed the temp relation will be written to the 
database. However, if a read or examine transaction is open, then 
the temp relation will be in the database in memory but will not 
be written back to secondary storage. */ 

idl_insert_back ( relational_relation, database->relat ions , 
temp_relation) ; 

} 

else /* else part of if (compatible)*/ 

{ 

idl_rai se ( IDL_ERROR , 

"The two relations are not union compatible i ") ; 

} 

} 

else /* else part of if (foundl && found2) */ 

{ 

report_union_error ( foundl , f ound2 ) ; 

} 

} 



/ 



/ 
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/* di f f erence_parse_action is called by the brw_input operation within the 
set_diff_op function. Difference parse action takes the query string and 
parses it into the two operand relations R1 and R2 . */ 

static void difference_parse_action (query) 
char* query; 

{ 

char *Rl_ptr, *char_ptr; 
integer size,i; 
boolean done = false; 

char_ptr = query; 

/* allocate room for parse of the union op parameters 
R1 will hold the first parameter and R2 the second */ 
size = St rlen (query } ; 

R1 = . (char* ) cal loc( (size+1) ,sizeof (char) ) ; 

R2 = (char* ) calloc ( (size+1) , sizeof (char) ) ; 

Rl_ptr = R1 ; 

/* do the parse */ 
charjtr = query; 

/* note; if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' union ' could not be 
found */ 

while (!done && size > 0) 

{ 

if (*char_ptr i= ' '} /* if not a space copy the char into R1 */ 

{ 

*Rl_ptr=*char_ptr; 

++char_ptr; 

++Rl_ptr; 

--size; 

} 

else /* we may have hit the delimeter for the first parameter */ 

{ 

/* check to see if next char is a which is the delimeter between 
the two parameters */ 

if (strncmp (char_ptr , " - ",3) == 0) /* then it is difference sentinal */ 
{ 

for (i =0; i < 3;++i) /* jump past the delimeter */ 

( 

++char_ptr; 

--size; 

} 

strcpy (R2 , char_ptr) ; /* copy second parameter into R2 */ 
done=true; 

} 

else /* the space is part of the first parameter, so put in R1 */ 

( 

/* space is part of first relation name so keep it */ 
*Rl_ptr=*char_ptr; 

++char_ptr; 

++Rl_ptr; 

— size; 

} 

} 

} 

if (size 1= 0) /* size only = 0 if union was not found in the query-*/ 

NULL; 

else 

idl_raise ( IDL_ERROR, 

"There is an error in your difference query! Try Again."}; 



} 



/* reported! fference_error reports errors as the name implies. It was taken out 
of set_diff_op and made into a separate function to make set_diff_op more 
readable. This has also been done with the other four operations in 
the R/OODBMS. */ 

void report_dif ference_error ( foundl , found2 ) 
boolean f oundl , f ound2 ; 

{ 

if { ! f oundl ScSc !found2) 

{ 

idl_rai se { IDL_ERROR , 

"Neither relation is in this database!"); 

} 

else 

{ 

if (Ifoundl) 

{ 

idl_raise { IDL_ERROR, 

"R1 {the first parameter) is not in this database!"); 

} 

if (!found2) 

{ 

idl_raise ( IDL_ERROR, 

"R2 (the second parameter) is not in this database!"); 

} 

} 

if (f oundl &Sc found2) 

{ 

idl_raise ( IDL__ERROR, 

"A SERIOUS ERROR HAS OCCURED IN THE DIFFERENCE OPERATION!"); 

} 
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/* set_diff_op is executed when Difference is selected within the browser. 

The syntax for the operation allows the user to input the two relations 
to be operated on and then creates the resultant relation. It calls 
di f f erence_parse_action, ini t_temp_rel , check_union_compatabil ity 
and report_dif ference_error . */ 

★ ★★**★*★*★★★*★★*★*★**■★★★***★•****•*★**★**★*★****★*★**★*•*■★***•*•■*■★*■*■**★★★*********** 

Difference Method 

★ ★*★***★***★★*★★★★★★★★★*******★★★***★★★★*★★**★**★*•****★*★*•*■•*■**•**★★**■*■■*■*■*■•*■*•■*••*••*•** 



idl_routine void set_di ff_op ( relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , ptr__R2 , temp_relation ; 
relational_database database; 
idl_trans_mode tmode; 
idl_univ root; 

string parameterl , parameter2 ; /* references to the parameters R1 and R2 */ 

static integer temp_rel_num = 0, index = 0; 
idl_transaction tr; 

boolean foundl , found2 , is_wri table = false , duplicate = true, compatible = false 



tr = idl_get_trans ( relation) ; 

tmode = idl_trans_mode_defaul t ; 

root = idl_trans_get_root ( tr) ; 

database = idl_to (relational_database, root ) ; 

' foundl = false; 
found2 = false; 

is_writable = { idl_trans_wri te_count ( tr) > 0); 

brw_input ( "Di f f erence Query", 

"Please input the Difference query (R1 - R2 ) : " 

OL, 0L,0L, false, 

dif ference_parse_action) ; 

/* copy the C strings R1 and R2 into IDL strings */ 
parameterl = idl_copy_string { tr , R1 ) ; 
parameter2 = idl_copy_string { tr , R2 ) ; 



/* search the database for the two relations: R1 and R2 */ 
idl_linked_for {relational_relation,database->relations, rel ) 

{ 

if {strcmp (rel->relation_name, parameterl) == 0) /* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 

} 



if {strcmp (rel->relation_name, parameter2 ) == 0) /* found relation 2 */ 

{ 

ptr_R2 = rel; 
found2 = true; 

} 

} idl_end_for 



if (foundl && found2) 

{ 

/* check for union comparability */ 

compatible = idl_vop (ptr_Rl, relational_relation, check_union_compatability 

(ptr_Rl , ptr__R2 ) ) ; 

if (compatible) 

{ 

temp_relation = ini t_temp_rel (ptr_Rl , ptr_R2 ) ; 
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/* don't insert any tuples from R1 that are in R2 into the 

resultant relation. Thus, have to check the tuple key with each 
tuple in R2 before entering a tuple into the resultant relation */ 



idl_linked_for ( relational_tuple, ptr_Rl-> tuples , rl_tuple) 

{ 

idl_linked_for (relational_tuple, ptr_R2->tuples, r2__tuple) 

{ 



/* equal_to takes the two tuples and determines if 
they have the same attribute values. If yes, 
then they are equal. It returns a boolean. */ 

duplicate = idl_vop (rl_tuple, relational^tuple, equal_to, 

( rl_tuple, r2_tuple, index) ) ; 

if (duplicate) /* then don't insert tuple into result */ 

{ 

break; 

get out of loop cuz found tuple was a duplicate */ 

} 

) idl_end_for 



) 



if ( ! duplicate) 

{ 

idl_insert_back ( relational_tuple, 

temp_relation->tuples , rl_tuple) ; 

) 

idl_end_for 



/* If a write transaction is open when this command is executed then 
if it becomes committed the temp relation will be written to the 
database. However, if a read or examine transaction is open, then 
the temp relation will be in the database in memory but will not 
be written back to secondary storage. */ 

idl_insert_back ( relational__relation, database->relations , 
temp_relation) ; 

} 

else /* else part of if (compatible)^/ 

{ 

idl_raise ( IDL_ERROR, 

"The two relations are not union compatible!"); 

} 

} 

else /* else part of if ( f oundl && f ound2 ) */ 

{ 

report_di f f erence_error ( f oundl , found2 ) ; 

} 

} 

/*==========================================================================*/ 
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/* Cartesian_parse_action is called by the brw_input operation within the 
cart_prod_op function. Cartesian parse action takes the query string and 
parses it into the two operand relations R1 and R2 along with the name 
of the resultant relation, R3 . */ 

static void Cartesian_parse_act ion (query ) 
char* query; 

{ 

char *Rl_ptr, *char_ptr, *R3_ptr; 
integer size,i; 

boolean done = false, delimeterl = false; 
char_ptr = query; 

/* allocate room for parse of the Cartesian product op parameters 
R1 will hold the first parameter and R2 the second */ 
size = St rlen (query ) ; 

R1 = (char*) calloc ( (size+1) ,sizeof (char) ) ; 

R2 = (char* ) calloc ( (size+1) , sizeof (char) ) ; 

R3 = (char* ) calloc ( (size+1 ), sizeof (char) ) ; 

/* set pointers to move along R1 and R3 as characters are copied in one 
at a time. */ 

R3_ptr = R3 ; 

Rl_ptr = Rl; 

/* do the parse */ 
char_ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 

problem with the query because the delimeter ' = ' or " X ' could not be 
found */ 

while (Idone && size > 0) 

{ 

if (*char_ptr != ' ') /* if not a space copy the char into R3 */ 

{ 

if ( ! del imeterl ) 

{ 

*R3_ptr=*char_ptr; 

++char_pt r; 

++R3_ptr; 

--size; 

} 

else 

{ 

*Rl_ptr=*char_ptr ; 

++char_ptr; 

++Rl_ptr; 

- - s i z e ; 

} 

} 

else /* we may have hit the a delimeter */ 

{ 

if ( ! delimeterl ) 

{ 

/* check to see if next char is a - which separates the 

resultant relation name from the other relations in the query - 
which is the delimeter between the first two parameters */ 
if (strncmp (char_ptr, " = ",3) == 0) /* then it is = sentinal */ 

{ 

delimeterl = true; 

for (i = 0; i < 3;++i) /* jump past the delimeter */ 

( 

++char_ptr; 

— size; 

} 

} 

else I* the space is part of the first parameter, so put in Rl */ 
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space is part of first relation name so keep it */ 
*R3_ptr=*char_ptr ; 

++char_^tr; 

++R3_ptr; 

--size; 



else 

{ 



/* check to see if next char is a " X " - which separates the 
two operands of the operation - which is the delimeter 
between the last two parameters */ 

if {strncmp {char_ptr, " X ",3} == 0} /* then it is X sentinal */ 

{ 

for {i =0; i < 3;++i) /* jump past the delimeter */ 

{ 

++char_pt r; 

--size; 

} 

strcpy {R2 , char_ptr) ; /* copy second parameter into R2 */ 
done=true ; 

) 

else /* the space is part of the first parameter, so put in R1 */ 

{ 

/* space is part of first relation name so keep it */ 

* Rl_p t r = * cha r_p t r ; 

++cha r_ptr; 

++Rl_ptr; 

--size ; 

} 



} 

if {size != 0) /* size only = 0 if union was not found in the query */ 
NULL; 
else 

idl_raise (IDL_ERROR, ''There is an error in your query! Try Again."); 
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/* report_Cart_product_error reports errors. It was taken out 

of cart_prod_op and made into a separate function to make cart_prod_op more 
readable. This has also been done with the other four operations in 
the R/OODBMS. */ 



void report_Cart_product_error ( foundl , found2 , found3 ) 
boolean foundl , found2 , found3 ; 

{ 

if (! foundl ScSc ! found2 && !found3) 

{ 

idl_raise ( IDL_ERROR, 

"None of the three relations are in this databasel"); 

} 



else 

{ 

if (! foundl) 

{ 

idl_rai se ( IDL_ERROR , 

"R1 is not in this database!"); 

} 

if (!found2) 

{ 

idl_rai se ( IDL_ERROR , 

"R2 is not in this database!"}; 

} 

if (!found3) 

{ 

idl_raise ( IDL_ERROR, 

"R3 is not in this database!"); 

} 

if (foundl Sc& found2 ScSc found3) 

{ 

idl_raise (IDL_ERROR, 

"A SERIOUS ERROR HAS OCCURED !!!!!! Regroup. Try Again."); 

) 



) 



} 
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/* cart_prod_op is executed when CartesianProduct is selected within the 
browser. The syntax for the operation allows the user to input the two 
relations to be operated on along with the name of the resultant relation. 
It calls Cartesian_parse_action, report_Cart_product_error , and 
insert_tuples . */ 



***************:it****** 



********************'************'**'**‘************** 



****** 



Cartesian Product Method 



**************** 



*************************************************************** 



idl_routine void cart_prod_op (relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , ptr_R2 , ptr_R3 , temp_relation; 
relational_database database; 
idl_trans_mode tmode; 
idl_univ root; 

string parameterl , parameter2 , resul t_rel ; /* references to the parameters 

R1 , R2 and R3 respectively */ 

idl_transaction tr; 
boolean f oundl , found2 , f ound3 ; 

boolean is_writable = false , duplicate = true, compatible = false; 

tr = idl_get_trans { relation) ; 

tmode = idl_trans_mode_defaul t ; 

root = idl_trans_get_root { tr) ; 

database = idl_to { relational_database , root ) ; 

foundl = false; 

found2 = false; 

found3 = false; 

is_writable = { idl_trans_write_count { tr) > 0) ; 

brw_input { "Cartesion Product Query", 

"Please input the Cartesian product query (R3 = R1 X R2 ) : ", 

OL, OL, OL, false, 

Cartesian_parse_action) ; 

/* copy the C strings R1 and R2 into IDL strings */ 
parameterl = idl_copy_s tring { tr , R1 ) ; 
parameter2 = idl_copy_s tring { tr , R2 ) ; 
result_rel = idl_copy_string { tr , R3 ) ; 

/* don't do anything if the resultant relation is one of the two operands. 
However, the resultant relation can be one that exists in the data. 

In this case, the specified resultant relation will be over written. */ 



if 



{l{strcmp (result_rel , parameterl ) ==0 ) && 
1 (strcmp (resul t_rel , parameter2 ) ==0 ) ) 



/* search the database for the three relations: Rl, R2 and R3 
idl_linked_f or (relational_relation,database->relations, rel ) 

{ 



if (strcmp (rel->relation_name, parameterl ) == 0) 
/* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 



*/ 



if (strcmp 
/* found 
{ 

ptr_R2 
f ound2 



(rel->relation_name, parameter2 ) 
relation 2 */ 

= rel; 

= true; 



== 0 ) 
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if {strcmp {rel ->relation_name, resul t_rel ) == 0) 

/* found relation 3 */ 

( 

ptr_R3 = rel; 
found3 = true; 

) 

} idl_end_for 

if (foundl ScSc found2 && found3) 

{ 

/* perform concatenation of tuples for Cartesian product. 

Note, in this implementation, the resultant relation already 
exists in the database. Thus, there is no need to insert any 
new relations into the database. We only have to fill in the 
resultant relation structure that already exists. */ 

ptr_R3 = idl_vop {ptr_R3->tuple_type, relational_tuple, insert_tuples , 
(ptr__Rl , ptr_R2 , ptr_R3 ) ) ; 



} 

else 



{ 

report_Cart_product_error { foundl , f ound2 , f ound3 ) ; 

} 



} /* if result relation is one of operands */ 
else 
{ 

idl_raise { IDL_ERROR, 

"R3, the resultant relation is one of the two operand relations . \nlt 
must be a relation in the database but not\none of the two operands!"); 

} 

} 
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char *Attr_list; /* allows global access to the attribute list for the project 

operation */ 

/* Project_parse_action is called by the brw_input operation within the 
project_op function. Project parse action takes the query string and 
parses it into the single operand relation Rl, the result relation R2 
along with the attribute list that is to be projected. */ 

static void Project _parse_act ion (query ) 
char* query; 

{ 

char *Rl_ptr, *char_ptr, *R2_ptr; 
integer size, i ; 

boolean done = false, delimeterl = false; 
char_ptr = query; 

/* allocate room for parse of the project op parameters 
R1 will hold the relation being operated on, 

Attr_list the list of attr to be projected, and 
R2 the resultant relation */ 
size = St rlen (query) ; 

R1 = (char* ) calloc ( (size+1 ), sizeof (char )) ; /* R1 is global */ 

Attr_list = (char* ) calloc (( size+1 ), sizeof (char) ) ; 

R2 = (char* ) calloc ( (size+1 ), sizeof (char) ) ; /* R2 is global */ 

/* set pointers to move along R1 and R2 as characters are copied in one 
at a time. */ 

R2_ptr = R2; 

Rl_ptr - Rl; 

/* do the parse */ 
char _ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' = ' or ' project ' 
could not be found */ 
while (‘done && size > 0) 

{ 

if (*char_ptr 1 = ' ') /* if not a space copy the char into R2 */ 

{ 

if ( ! delimeterl ) 

{ 

*R2_ptr=*char_ptr; 

++char_ptr ; 

++R2_ptr ; 

--size; 

} 

else 

{ 

*Rl_ptr=*char_ptr ; 

++char_ptr; 

+ +Rl__ptr; 

- - s i z e ; 

} 

} 

else /* we may have hit a delimeter */ 

{ 

if ( Idelimeterl) 

{ 

/* check to see if next char is a - which separates the 

resultant relation name from the other relation in the query - 
which is the delimeter between the first two parameters */ 
if (strncmp (char^ptr, " = ",3) == 0) /* then it is = sentinal */ 

{ 

delimeterl = true; 

for (i = 0; i < 3;++i) /* jump past the delimeter */ 

{ 
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++char_ptr; 

--size; 

} 

} 

else /* the space is part of the first parameter, the resultant 
relation name, so put in R2 */ 

{ 

*R2_ptr=*char_ptr; 

++char_ptr; 

++R2_ptr ; 

- - s i z e ; 

} 

} 

else /* we have already found the first delimeter */ 

{ 

/* check to see if next char is a " p " - which is 
part of the delimeter " project "between the last 
two parameters */ 

if (strncmp (char_ptr, " project ",9) == 0) ‘ 

/* then it is project */ 

{ 

for (i = 0; i < 9;++i) /* jump past the delimeter */ 

{ 

++char_ptr; 

- - s i z e ; 

} 

strcpy (Attr_list , char_ptr) ; 

/* copy list of attributes into Attr_list and now parse the 
list of attributes */ 

done=true; 

} 

else /* the space is part of the' first parameter, so put in R1 */ 

{ 

/* space is part of first relation name so keep it */ 

* Rl_p t r= * char_p t r ; 

++char_ptr; 

++Rl_ptr ; 

--size; 



if (size != 0} /* size only = 0 if union was not found in the query */ 
NULL; 
else 

idl_raise { IDL__ERROR, "There is an error in your query! Try Again."); 
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/* report_pro ject_error reports errors. It was taken out 

of project_op and made into a separate function to make project_op more 
readable. This has also been done with the other four operations in 
the R/OODBMS. */ 

void report_pro ject_error ( f oundl , f ound2 , attr_f ound) 
boolean f oundl , f ound2 , attr_found; 

{ 

if ( 1 f oundl SlSc !found2) 

{ 

idl_raise (IDL_ERROR, 

"Neither of the two relations are in this database!"); 



else 

{ 

if ( ! attr_f ound) 

{ 

idl_raise ( IDL_ERROR, 

"All of the attributes in the attribute list \nare not in Rl!") 

} 

if ( ! f oundl ) 

{ 

idl_raise ( IDL_ERROR, 

"Rl is not in this database!"); 

} 

if (!found2) 

{ 

idl_raise ( IDL_ERROR, 

"R2 is not in this database!"); 

} 

if (f oundl && found2) 

{ 

idl_raise (IDL_ERROR, 

"A SERIOUS ERROR HAS OCCURED !!!!!! Regroup. Try Again."); 

} 



} 



} 



/* project_op is executed when Projection is selected within the 

browser. The syntax for the operation allows the user to input the single 
relation to be operated on along with the name of the resultant relation and 
the attribute list to be projected. It calls Pro ject_parse_action, 
report_pro ject_error , and insert_f ields . */ 

ieicicicicicicic*icicicicicicicicicicieie-icicie*icicicicieicici(ic*-k*icicicicicicic-kicicicicicicici(icieie-kicicicicicicicicieicicicicie*ieicic-kicie*ic 

Project Method 



idl_routine void project_op (relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , ptr_Attr_list, ptr_R2 , temp_relation; 
relational_database database; 
idl_trans_mode tmode; 
idl_univ root; 

string parameterl , attr_string, resul t_rel ; /* references to the parameters 

Rl, attr list and result 
relation respectively */ 

idl_transaction tr; 

boolean f oundl , found2 , done, attr_f ound; 

boolean is_writable = false, duplicate = true, compatible = false; 
char *attr_ptr, *delimeter = delimeter between elements 

in attribute list */ 



string *attr_list [100 ] ; 

integer i=l , count , size, index, index_array [ 100 ] , i i=0 ; 
idl_linked_elera (relational_tuple)‘ resul t_tuple; 

tr = idl_get_trans ( relation) ; 

tmode = idl_trans_mode_defaul t; 

root = idl_trans_get_root (t r) ; 

database = idl_to ( relational_database, root) ; 

foundl = false; 

found2 = false; 

done = false; 

is_writable = ( idl_trans_wri te_count ( tr) > 0) ; 



brw_input (" Project Query", 

"Please input the Project query (R2 = R1 project Attrjist) : ", 
OL, OL, OL, false. 

Pro ject_parse_action) ; 



/* copy the C strings Rl, R2 and Attr_list into IDL strings */ 
parameterl = idl_copy_string ( tr , Rl ) ; 
result_rel = idl_copy_string ( tr , R2 ) ; 
attr_string = idl_copy_st ring ( tr , Attr_list ) ; 

/* parse tokens in attribute string */ 

if ((attr_ptr = strtok (attr_string, delimeter) ) == NULL) 

{ 

/* error, no token */ 
i dl_ra i se { I DL_ERROR , 

"You did not list any attribute/f ield names inXnyour project query! 
Try again, meathead!"); 

) 

else 

{ 

attr_list[01 = idl_new_string ( tr, 80) ; 
attr_list[0] = idl_copy_string { tr, a ttr_ptr) ; 

) 
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while ( (attr_ptr = strtok (NULL, delimeter) ) != NULL) 

{ 

attr_list [i] = idl_new_string ( t r , 80 ) ; 
attr_list [i] = idl_copy__string ( tr , attr_ptr) ; 

+ + i ; 

} 



/* don't do anything if the resultant relation is the operand relation. 
However, the resultant relation can be one that exists in the data. 

In this case, the specified resultant relation will be over written. */ 



if (!(strcmp (result_rel , parameterl ) ==0 ) ) 

{ 

/* search the database for the two relations: R1 and R2 */ 
idl_linked_for ( r el at iona l_re la t ion, database- >rel at ions , rel ) 
{ 

if (strcmp ( rel->relation_name, parameterl ) == 0) 

/* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 

} 



if (strcmp ( rel->relation_name, result_rel ) == 0) 
/* found relation 2 */ 

{ 

ptr_R2 - rel; 
found2 = true; 

} 

} idl_end_for 



count = i; /* count is the number of tokens - 1 */ 



/* check each attr name in the attr list of the project operation to 
ensure that the field exists in the relation R1 */ 



f or ( i=0 ; i<count ; ++i ) 

{ 

attr_found = false; 
ii = 0; 

idl_array_f or ( relational_name, ptr_Rl->att ribute_names , aname) 

{ 

ii++; /* position in attribute list */ 

if (strcmp (aname->name, attr_list [i ] ) == 0) /* attr name in attr 

list is a field 
of R1 */ 

{ 

attr_found = true; 
index_array [i ] =ii ; 
break; 

} 

} idl_end_for 

if ( ! attr_f ound) 

{ 

break; /* an attr in the project attr list is not 
in the relation R1 . Thus, the operation 
cannot be performed */ 

} 

} 

if (foundl ScSc found2 && attr_found) 

{ 

/* everything is ok, perform projection operation on relation R1 . 
Note, in this implementation, the resultant relation already 
exists in the database. Thus, there is no need to insert any 
new relations into the database. We only have to fill in the 
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resultant relation structure that already exists. */ 

I* iterate through every tuple of R1 and copying only the desired 
fields into R2 . Note: R1 and R2 will have the same number of 
tuples but the relations will be of differing degree. 



ptr_R2 = idl_vop (ptr_R2->tuple_type, relational_tuple, insert_f ields, 
(ptr_Rl , ptr_R2 ) ) ; 



} 

else 

{ 

report_proj ect_error ( f oundl , f ound2 , attr_f ound) ; 

} 

} 

else /* end of if ( ! (strcmp ( result_rel , parameterl ) ==0) ) */ 

{ 

idl_raise (IDL_ERROR, 

"R2/ the resultant relation is also the operand. \nlt must be a 
relation in the database but not the operand!"); 

} 



} 

/* = = =:= = = = = = = = = = = = = = = =:==: = = = = = = = = = = = = = = = = = ==== = = = = = = = = = = =:=: = = = = = = = = = = = == = = = = = = = */ 
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char *Attr ; *Obj , *Cornp_opr ; /* allows global access Co three stings: an attribute 

name used for the select condition, the name of 
the object created Chat contains the select values 
for comparison, and the comparison operator name. */ 

/* Select_parse_action is called by the brw_input operation within the 
select_op function. Select parse action Cakes the query string and 
parses it into the single operand relation Rl, the attribute that is 
going to be used Co select upon, the comparison operator to be used, 
and the name of the object Chat contains Che attribute value to be 
compared with.*/ 

static void Se lect_parse_act ion (query ) 
char* query; 

{ 

char *Rl_ptr, *char_ptr, *Attr_ptr, *Comp_opr_ptr ; 
integer size, i; 

boolean done = false, delimeterl = false; 
char_ptr = query; 

/* allocate room for parse of the select op parameters 
Rl will hold the relation being operated on, 

Attr Che attr that selection will be made on, 

Comp_opr the comparison operator (=,<,>), and 
Obj holds the values to be compared with */ 

size = strlen (query ) ; 

Rl = (char* ) calloc ( (size+1 ), sizeof (char )) ; /* Rl is global */ 

Attr = (char* ) cal loc ( (size+1 ), sizeof (char )) ; /* Attr is global */ 

Obj = (char*) calloc ( (size+1 ), sizeof (char) ) ; /* Obj is global */ 

Comp_opr = (char* ) calloc ( (size+1) , sizeof (char) ) ; /* Comparison Operator 

is global */ 

/* set pointers to move along Rl and Obj as characters are copied in one 
at a time. */ 

Attr_ptr = Attr; 

Rl_ptr = Rl ; 

Comp_opr_ptr = Comp_opr; 

/* do the parse */ 
char_ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' select ' 
could not be found */ 
while (idone && size > 0) 

{ 

if (*char_pCr != ' ') /* if not a space copy the char into Rl */ 

{ 

if (! delimeterl ) 

{ 

*Rl_ptr=*char_ptr ; 

++char_pt r; 

++Rl_ptr; 

--size; 

} 

else 

{ 

*Attr_ptr=*char_ptr; 

++char_ptr; 

++Attr_ptr; 

--size; 

} 

} 

else /* we may have hit a delimeter */ 

{ 

if (! delimeterl ) 
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/* check to see if next char is a "select" - 

which is the delimeter between the first two parameters */ 
if (strncmp (char_ptr, " select ",8) == 0) /* then it is select */ 

{ 

delimeterl = true; 

for (i =0; i < 8;++i) /* jump past the delimeter */ 

{ 

++char_pt r; 

--size; 

) 

} 

else /* the space is part of the first parameter, the operand 
relation name, so put in R1 */ 

{ 

*Rl_ptr=*char_ptr ; 

++char_ptr ; 

++Rl_ptr; 

--size; 

} 

} 

else /* we have already found the first delimeter */ 

{ 

/* check to see if the next token is a comparison operator */ 

if (strncmp (char_ptr, " = ",3) == 0 II 
strncmp (char^ptr, " < ",3) == 0 II 
strncm.p (char_ptr, " > ",3) == 0) 

{ 

++char_ptr; 

--size; ^ 

for {i = 0; i < l;++i) /* copy comparison operator */ 

{ • 

* Comp_op r_p t r = * char_p t r ; 

+ +Comp_op r_p t r ; 

++char_ptr; 

--size; 

} 

+ +char_ptr; 

--size; 

strcpy (Obj , char_ptr) ; 
done=true ; 

} 

else if (strncmp (char_ptr, " /= ",4) == 0 I I 
strncmp (char_ptr , " <= ",4) == 0 I | 

St rncmp (char_ptr, " >= ",4) == 0) 

{ 

++char_ptr; 

--size; 

for (i = 0; i < 2;++i) /* copy comparison operator */ 

{ 

*Comp_opr_ptr=*char_ptr; 

+ + C omp_op r_p t r ; 

++char_ptr; 

- -size; 

) 

++char_ptr; 

--size; 

strcpy (Obj , char_ptr) ; 
done=true ; 

) 

else /* the space is part of the first parameter, so put in R1 */ 

{ 

/* space is part of first relation name so keep it */ 
*Attr_ptr=*char_ptr; 

->^+char_pt r; 

++Attr_ptr; 

--size; 



148 



if {size != 0) /* size only = 0 if union was not found in the query */ 
NULL; 
else 

idl_raise (IDL_ERROR, "There is an error in your query! Try Again."); 



) 
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report_select_error reports errors. It was taken out 

of select_op and made into a separate function to make select_op more 
readable. This has also been done with the other four operations in 
the R/OODBMS. */ 



void report_select_error ( foundl , f ound2 y attr_f ound) 
boolean foundl, f ound2 , attr_found; 



{ 



if (! foundl ScSc lfound2) 

{ 

idl_raise (IDL_ERROR, 

"Neither of the two relations are in this database!"); 

} 

else 

{ 

if ( ! attr_found) 

{ 

idl_raise (IDL_ERROR, 

"The attribute specified for comparison is not in Rll"); 

} 

if (! foundl) 

{ 

idl_raise ( IDL_ERROR, 

"R1 is not in this database!"); 



) 

if 

{ 



} 



( ! found2 ) 

idl_raise (IDL_ERROR, 

"The object for comparison is not in this database!"); 



if (foundl ScSc found2) 

{ 

idl_raise (IDL_ERROR, 

"A SERIOUS ERROR HAS OCCURED !!!!!! Regroup. Try Again.") 



} 



} 
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/* select_op is executed when Selection is selected within the browser. The 
sytax for the operation allows the user to input the single relation to be 
operated on, attributed name to select upon, the comparison operator, and 
the name of the object that contains the attribute value for comparison. 
The comparison object must be an instantiation of an existing relation in 
the database. It must have only one tuple that has one attribute filled 
with values, the attribute that you want to use for comparison. Then, the 
relation being operated on is found and each tuple has the specified attr 
comparied with the comparison objects attr value using that relations 
comparison operator that was specified in the query. 

Select_op calls the functions: Select_parse_action , report_selec t_error, 
and init_temp_rel . */ 

Select Method 



idl_routine void select_op { relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , ptr_Attr , ptr_Obj , temp_relation; 

relational_database database; 

idl_trans_mode tmode; 

idl_univ root; 

integer operator; 

string parameterl , attr, comp_obj , comp_opr; /* references to the parameters 

Rl, attr, comparison object, 
and comparison operator 
respectively */ 

idl_transaction tr; 

boolean f oundl , f ound2 , a ttr_f ound; 

boolean is_writable = false, select = false; 

char *attr_ptr, *delimeter = /* delimeter between elements 

in attribute list - no spaces allowed */ 



integer i=l , count, size, index=0, ii=0 ; 
idl_linked_elem (relational_tuple) comp_tuple; 

tr = idl_get_trans { relation) ; 

tmode = idl_trans_mode_defaul t; 

root = idl trans get root(tr); 

database = idl_to { relational_database , root ) ; 

foundl = false; 

found2 = false; 

attr_found = false; 

is_writable = ( idl_trans_write_count { tr ) > 0); 
brw_input { "Select Query", 

"Please input the Select query {Rl select attr comp_op object): ", 
OL, OL, OL, false, 

Select_parse_action) ; 

/* copy the C strings Rl, Obj and Attr into IDL strings */ 
parameterl = idl_copy_string ( tr , Rl) ; 
comp_obj = idl_copy_string(tr,Obj ) ; 
attr = idl_copy_string ( tr , Attr) ; 

if (strcmp (Comp_opr, "=" ) == 0) 
operator = 1; 

else if ( strcmp (Comp_opr , ">" ) == 0) 
operator = 2; 

else if ( strcmp (Comp_opr, "<" ) == 0) 
operator =3; 

else if (strcmp (Comp_opr, "/=" ) == 0) 
operator = 4; 
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0 ) 



else if (strcmp (Comp_opr, ">=" ) == 
operator = 5; 
else if (strcmp (Comp_opr, "<=" ) == 0) 
operator = 6; 
else 

idl_raise (IDL_ERROR, 

"It is hard to believe that this error could occure!"); 

/* search the database for the two relations: R1 and Obj */ 
idl_linked_for ( rel at ional_relat ion, database- >rel at ions , rel ) 

{ 

if (strcmp {rel ->relation_name, parameterl ) == 0) 

/* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
found 1 = true; 

} 

if (strcmp ( rel ->relation_name, comp _obj ) == 0) 

/* found the comparison object */ 

{ 

ptr_Obj = rel; 
found2 = true; 

} 

) idl_end_for 



/* check the attr name in the of the select operation to 
ensure that the field exists in the relation R1 */ 

idl_array_f or (relational_name, ptr_Rl->attribute_names , aname) 

( 

ii++; /* keep track of position of attribute in the relation schema - 
that is, the attribute list */ 

if (strcmp (aname->name , attr ) == 0) /* attr name in attr list is a field 

of R1 */ 

( 

attr_found = true; 
index = ii; 
break; 

} 

) idl_end_for 

if (foundl ScSc found2 && attr_found) 

{ 

/* Everything is ok, perform select operation on relation R1 . 

Iterate through every tuple of R1 and compare the field named in 
the 'attr' variable with the values of the object specified in 
comp_obj . using the specified comparison operator in Comp_opr. */ 

temp_relation = init_temp__rel(ptr_Rl,ptr_Obj); 

idl_linked_f or ( relational_tuple , ptr_Obj ->tuples , c tuple) 

{ 

idl_linked_for ( relational_tuple , ptr_Rl->tuples , rl_tuple) 

{ 

select = false; 
switch (operator) 

{ 

case 1: /* = */ 

select = idl_vop (rl_tuple, relational_tuple, equal_to, 
(rl_tuple, ctuple, ii) ) ; 

break; 

case 2: /* > */ 

select = idl_vop ( rl_tuple, relational_tuple, greater_than, 
(rl_tuple, c tuple, ii) ) ; 

break; 

case 3: /* < */ 
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select = idl_vop ( rl_tuple, relational_tuple, less_than, 
(rl_tuple, ctuple, ii) ) ; 

break; 
default : 

idl_raise ( IDL_ERROR, 

"Problems with operator in select operation"); 

break; 

} 



if (select) 

idl_insert_back ( relat ional_tuple, 

temp_relation->tuples , rl_tuple) ; 



} idl_end_for 
} idl_end_for 



} 



idl_insert_back ( relational_relat ion, database->relations, temp_relat ion) 

} 

else 

{ 

report_project_error ( f oundl , f ound2 , attr_f ound) ; 

} 
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y************************-************’*******-******************'********^******* 

*• 

* Class tuple methods 

* 

* equal_to 

^ less_than 

* greater_than 

* 

* initialize_tuple 

* insert_f ields 

* insert_tuples 

* 

******^*****-Jt***^*iririr**-*r***-*i**-****Kt*****i(t****-*r*****************lt***^*-*******'* j 
★ *****•★★★***■**★**★★*★**★****•**★***•*****★**■*★★★**•**★*★**★★***■*■**★•**★★***■****★*★★* 



Class Tuple Methods 






/* this is the default duplicate tuple check function */ 

idl_routine boolean equal_to ( rl_tuple , r2_tuple, index) 
relational_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple ) ; 

/* both of these are pointers, so if they point to the same 
object, then they are identical tuples. However, two tuples 
that don't point to the same objects may have the same values 
for the values of each of their individual objects. */ 

if {rl_tuple == r2_tuple) 
return true; 

else 

return false; 



/*==========================================================================*/ 

/* this function is called by create_tuple of class relation if there has been 
no redefinition of this method by a subclass of tuple. If this function is 
executed, then there is an error since it must be over-written. */ 

idl_routine relational_tuple initialize_tuple (tuple_type) 
relational_tuple tuple_type; 

( 

relational_tuple new_tuple; 

idl_transaction tr = idl_get_trans ( tuple_type ) ; 
idl_raise ( IDL_ERROR, 

"There is no method for initializing a tuple ofXnthe type that this 
relation contains."); 



/*==========================================================================*/ 

/* the default insert field inserts all fields of tuple into result_tuple 
by reference */ 

idl_routine relat ional_relation insert_fields (relation, result_rel ) 
relational_relation relation, result_rel; 

( 

idl_transaction tr = idl_get_trans ( relation) ; 
return result_rel = relation; 
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} 



/*==========================================================================*/ 

/* the default insert tuple inserts a tuple into result_tuple by reference */ 

idl_routine relational^relation insert_tuples (relation, result_rel) 
relational_relation relation, result_rel; 



{ 

idl_t ransaction tr = idl_get_trans ( relation) ; 
return result_rel = relation; 

} 



idl_routine boolean less_than ( rl_tuple, r2_tuple , index) 
relational_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans(rl_tuple); 
idl_raise ( IDL_ERROR, 

"No less than method has been specified for these relations . \nThe user 
must provide them. No default can be provided."); 

} 






idl_routine boolean greater_than ( rl_tuple, r2_tuple, index) 
relational_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple ) ; 
i dl_r a i se ( I DL_ERROR , 

"No greater than method has been specified for these relations . \nThe 
user must provide them. No default can be provided."); 

} 
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★ 

* class name methods 

* 

* name_key 

* name _print 
•*■ 

•*•**■*■*****•******★*■*********★*★★**•★*■*******★**■*■*★★*★**•★*****■*★**★*★★**★*****■*•■*■* ! 



idl_routine void name_key (name) 
relational_name name; 

{ 

idl_univ u; 

if ( idl_string_size (name->name) == 0) 

{ 

dpy_cstring ( " * * Unnamed/No Attributes **"); 

} 

else 

{ 

u = idl_to ( idl_univ, name->name) ; 
idl__vop (u, idl_univ, idl_key, (u) ) ; 

) 

} 

/*====================================================================:======*/ 

idl_routine void name_print (name, mode) 
relational_name name; 
dpy_dmode mode; 

{ 

idl_transaction tr =. idl_get_trans (name)'; 
boolean can_write = idl_trans_wri te_count ( tr) > 0; 
dpy_dmode model; 

model = mode; 
model. embed = 1; 

if (can_write) model. expand =1; 

if (model . expand > 1) 

{ 

idl_top (idl_any , idl_print , (name, mode) ) ; 

} 

dpy_a ttr(relati ona l_name , name , name , mode 1 ) ; 
dpy_eol 0 ; 
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y*-*:******************-***********-********'*:'*:*******'*******'*********-*:***'*:******* 



* Class emp_tuple methods 

* 

* emp_tuple_key 

* emp_tuple_print 

* emp_equal_to 

* initialize_emp_tuple 

* 

************************************************************************************** j 
*****★****★****★*★*★•*■*★********•*•*•****★**★★*********★★•*■•*•****•*■*•*•■**•*•***★•***•*★***■*■■*•* 

Class Emp_Tuple Methods 

★ **★*★********•*:★★★*★******★**•*★***★★*********★*★***•***★******★***•***•*:**★**★*★*** 



idl_routine void einp_tuple_key ( tuple) 
relational_emp_tuple tuple; 

{ 

idl_univ u; 

if (idl_string_size (tuple->person->lnaine) == 0) 

{ 

dpy_cstring ( " * * Unnamed Tuple **"); 

) 

else 

{ 

u = idl_to ( idl_univ, tuple->person->lname) ; 
idl_vop (u , idl_uni V, idl_key , (u ) ) ; 

} 

} 

idl_routine void emp_tuple_print (emp_tuple, mode) 
relational_emp_tuple emp_tuple; 
dpy_dmode mode; 

{ 

idl_transaction tr = idl_get_trans (emp_tuple) ; 
boolean can_write = idl_trans_wri te_count { tr) > 0; 
dpy__dmode model; 

model = mode; 
model. embed = 1; 

if (can_write) model. expand = 1; 

if (model .expand > 1) 

{ 

idl_top (idl_any , idl_j)rint , (emp_tuple, mode) ) ; 

} 

dpy_attr ( relational_emp_tuple , emp_tuple , person, model ) ; 

dpy_eol(); 

dpy_spacey ( 2L ) ; 

dpy^eol ( ) ; 

dpy_attr ( relational_emp_tuple, emp_tuple, phone, model ) ; 
dpy_eol ( ) ; 
dpy_spacey (2L) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_emp_tuple, emp_tuple, address , model ) ; 
dpy_eol { ) ; 

add widget in later */ 



} 

/*==========================================================================*/ 
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/* this function returns true if rl tuple is identical to r2 tuple and 
returns false otherwise. */ 

idl_routine boolean emp_equal_to (rl_tuple, r2_tuple, index) 
relational_emp_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans { rl_tuple) ; 

/* both of these are pointers, so if they point to the same 
object, then they are identical tuples. However, two tuples 
that don't point to the same objects may have the same values 
for the values of each of their individual objects. */ 

if {index == 0) /* compare the entire tuple - all attributes */ 

{ 

if (rl_tuple == r2_tuple) 
return true; 

else /* not the same objects but need to check attribute values */ 

{ 

/* need to check each attr value. The first time one is found 
that does not have the same value, the function stops and 
returns not dulicate (false). Only if all attr are identical 
does the function return duplicate (true) . */ 

if {! St rcmp (rl_tuple->person->f name , r2_tuple->person->f name) && 

! strcmp (rl_tuple->person->mname, r2_tuple->person->mname ) && 

! strcmp (rl_tuple->person->lname, r2_tuple->person->lname) && 

! strcmp (rl_tuple->person->bdate , r2_tuple->person->bdate ) Sf& 
rl_tuple->person->ssn == r2_tuple->person->ssn && 
i strcmp (rl_tuple->person->spouse, r2_tuple->person->spouse) && 

! strcmp (rl_tuple->address->street , r2_tuple->address->street ) && 
! strcmp (rl_tuple->address->city , r2_tuple->address->ci ty ) && 

! strcmp { rl_tuple->address->state , r2_tuple->address->state) && 

! strcmp { rl_tuple->address->zip, r2_tuple->address->zip ) && 

! strcmp { rl_tuple->phone->number , r2_tuple->phone->number ) ) 
return true; 
else 

return false; 

} 

} 

else /* compare only the attribute specified by the index */ 

{ 

switch (index) 

{ 

case 1 : 

if {! strcmp (rl_tuple->person->fname, r2_tuple->person->fname) && 

! strcmp (rl_tuple->person->mname, r2_tuple->person->mname ) && 

! strcmp (rl_tuple->person->lname, r2_tuple->person->lname ) 

! strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate ) && 
rl__tuple->person->ssn == r2_tuple->person->ssn && 

! strcmp (rl_tuple->person->spouse, r2_tuple->person->spouse) ) 
return true; 
else 

return false; 
break; 
case 2: 

if (1 strcmp (rl_tuple->address->street , r2_tuple->address->street ) && 
! strcmp (rl_tuple->address->city , r2_tuple->address->city ) && 

! strcmp (rl_tuple->address->state, r2_tuple->address->state) && 

! strcmp (rl_tuple->address->zip, r2_tuple->address->zip) ) 
return true; 
else 

return false; 
break ; 
case 3 : 

if { ! strcmp { rl_tuple->phone->number , r2_tuple->phone->number) ) 
return true; 
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else 

return false; 
break; 
case 4: 

idl_rai se ( IDL_ERROR , 

"Widget is not defined and thus can't be comparedl " ) ; 

break; 
default : 

idl_raise(I DL_E RROR , 

"An ugly error has occured in emp_equal_to" In- 
break; 



/* = = = = = = = = = = = = = = = = = rr== = === = = === = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = r= = = = = = = = =*/ 

/* this function returns true if rl tuple is less than r2 tuple and 
returns false otherwise. */ 

idl_routine boolean emp_less_than ( rl_tuple/ r2_tuple, index) 
relational_emp_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple) ; 

switch (index) 

{ 

case 1 : 

if ( (strcmp (rl_tuple->person->fnaine, r2_tuple->person->f name) < 0) && 
(strcmp (rl_tuple->person->mname, r2_tuple->person->mname) < 0) && 
(strcmp (rl_tuple->person->lname, r2_tuple->person->lname) < 0) ScSc 
(strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate) < 0) && 
rl_tuple->person->ssn < r2_tuple->person->ssn && 

( strcmp ( rl_tuple->person->spouse, r2_tuple->person->spouse) < 0) ) 
return true; 
else 

return false; 
break; 
case 2 : 

if ( (strcmp (rl_tuple->address->street , r2_tuple->address->street ) < 0) && 
(strcmp (rl_tuple->address->city, r2_tuple->address->city) < 0) ScSc 
(strcmp (rl_tuple->address->state, r2_tuple->address->state) < 0) && 
(strcmp (rl_tuple->address->zip, r2_tuple->address->zip) < 0)) 
return true; 
else 

return false; 
break; 
case 3 : 

if ( ( strcmp ( rl_tuple->phone->number, r2__tuple->phone->number) < 0)) 
return true; 
else 

return false; 
break; 
case 4: 

idl_raise ( IDL_ERROR, 

"Widget is not defined and thus can't be comparedl"); 

break; 
default : 

idl_rai se ( IDL_ERROR , 

"An ugly error has occured in emp_less_than" ) ; 

break; 

} 

} 



/*====================================================================: 

/* this function returns true if rl tuple is greater than r2 tuple and 



/ 



returns false otherwise. */ 



idl_routine boolean emp_greater_than ( rl_tuple , r2_tuple, index) 
relational_emp_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple) ; 

switch (index) 

{ 

case 1 : 

if (( St rcmp (rl_tuple->person->f name , r2_tuple->person->f name ) > 0) && 
(strcmp (rl_tuple->person->mname, r2_tuple->person->mname) > 0) && 
(strcmp ( rl_tuple->person->lname, r2_tuple->person->lname ) > 0) && 
(strcmp (rl_tuple->person->bdate, r2_tuple->person->bdate) > 0) && 
rl_tuple->person->ssn > r2_tuple->person->ssn && 

(strcmp (rl_tuple->person->spouse, r2_tuple->person~>spouse ) > 0) ) 
return true; 
else 

return false; 
break; 
case 2 : 

if ( (strcmp (rl_tuple->address->street , r2_tuple->address->street ) > 0) && 
(strcmp (rl_tuple->address->city , r2_tuple->address->city) > 0) && 
(strcmp (rl_tuple->address->state, r2_tuple->address->state) > 0) && 
(strcmp (rl_tuple->address->zip, r2__tuple->address->zip ) > 0)) 
return true; 
else 

return false; 
break; 
case 3 : 

if ( (strcmp (rl_tuple->phone->number , r2_tuple->phone->number) > 0)) 
return true; 
else 

return false; 
break ; 
case 4: 

idl_raise ( IDL_ERROR, 

"Widget is not defined and thus can't be compared!"); 

break; 
default : 

idl_raise(IDL_ERROR, 

"An ugly error has occured in emp_greater_than" ) ; 

break; 

} 

) 



/*==========================================================================*/ 

/* this function is called from create_tuple. It redefines the implementation 
for the class tuples method initialize_tuples . Specifically, a new employee 
tuple is created and given initial values (all of which are legal) . 

It returns a tuple to create_tuple which then allows the user to initialize 
this tuple with values. Each subtype of tuple needs to have a function 
like this. */ 

idl_routine relat ional_tuple initialize_emp_tuple ( tuple_type) 
relational_tuple tuple_type; 

{ 

relational_emp_tuple new_tuple; 
idl_transaction tr = idl_get_trans ( tuple_type) ; 
string empty = idl_copy_string ( tr , " " ) ; 

new_tuple = idl_new ( tr, relational_emp_tuple) ; /* must still assign 

legal values*/ 



new_tuple->person = idl_new (tr, relational_person) ; 
new_tuple->person->fname = empty; 
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new_tuple->person->mname = empty; 
new_tuple->person->lname = empty; 
new_tuple->person'>bdate = empty; 
new_tuple->person->ssn = 0; 
new_tuple->person->spouse = empty; 

new_tuple->address = idl_new( tr, relational_addr ) ; 
new_tuple->address->street = empty; 
new_tuple->address->city = empty; 
new_tuple->address->state = empty; 
new_tuple->address->zip = empty; 

new_tuple->phone = idl_new( tr, relational_phone_number) 
new_tuple->phone->number = empty; 

return idl_to (relational_tuple, new_tuple) ; 



} 
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★ ********★****★★★★★★***■*:********★★*★*★**»★*★**★*★★**★*************★****** 



* Class person methods 

* 

* person_k:ey 

* person_print 

* 



******* 



********************************************************************* ! 



idl_routine void person_key (person) 
relational_person person; 

{ 

boolean bl,b2,b3; 
bl = rexists (person, fname) ; 
b2 = rexists (person, mname) ; 
b3 = rexists (person, Iname) ; 
if (bl) 

( 

c^PY— cstring (person->f name) ; 
if (b2 I I b3) 

{ 

dpy_spacex(lL) ; 

) 

} 

if (b2) 

{ 

ciPY— cst ring (per son ->mname) ; 
if (b3) 

{ 

dpy_spacex (IL) ; 

) 

) 

if (b3) 

{ 

dpY—Cstring (person->lname) ; 

} 

if (! bl ! b2 £c£c ! b3 ) 

{ 

c5pY_cstring ( " * * No name **"); 

} 

} 

/*===========================================================================*/ 

idl_routine void person_print (person, mode) 
relational_person person; 
dpy_dmode mode; 

{ 

boolean bl,b2,b3; 

if (mode. expand > 1) 

{ 

idl_top (idl_any, idl_print, (person, mode) ) ; 
return; 

} 

bl = dexists (person, fname) ; 
b2 = dexists (person, mname ) ; 
b3 = dexists (person, Iname) ; 
if (mode. expand > 0) dpy_spacey ( IL) ; 
if (bl) 

{ 

dPY_attr( relational_person, person, fname, mode) ; 
if (b2 I t b3) 

{ 

dpY— spacex( IL) ; 

) 

} 

if (b2) 
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{ 



dpy_attr ( relational_person, person, mname, mode) ; 
if (b3) 

{ 

dpy_spacex ( IL) ; 

} 

} 

if (b3) 

{ 

dpy_attr(relational_person, person, lname,mode) ; 

} 

if (! bl && ! b2 i b3) 

{ 

dpy_cstring (" ** No name **"); 

) 

if (dexists (person, bdate) ) 

{ 

dpy_spacex ( IL) ; 
dpy_cst ring ("("); 

dpy_attr ( relational_person, person, bdate , mode) ; 
dpy_cs t ring (")"); 



else 

{ 

dpy_cstring ( " ** No Birth Date Entered **"); 

} 

if (dexists (person, spouse) M pdexists (person, sptr) ) 

{ 

if (mode. expand > 0 II I pdexists (person, sptr ) ) 

{ 

dpy_cs t ri ng ( " [ " ) ; 

dpy_attr ( relational_person, person, spouse, mode) ; 
dpy_cstring ( " ] " ) ; 

} 

if (pdexists (person, sptr) ) 

{ 

if (idl_get_display_embed ( relational_person, sptr) ) 

{ 

dpy_eol ( ) ; 

dpy_attr ( re la tional_person, person, sptr, mode) ; 

} 

else 

{ 

dpy_c s t r i ng ( " [ " ) ; 

dpy_attr ( relational_person, person, sptr, mode) ; 
dpy_cstring ( " ] " ) ; 

} 

} 

) 

dpy_eol ( ) ; 
dpy_spacey ( IL) ; 
dpy_cstring ( "SSN: " ) ; 

dpy_attr ( relational_person, person, ssn, mode) ; 
dpy_eol ( ) ; 

} 
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^■k-k*******-k*-k-k-kic-kicic-*-kicic**ic-kicic*i(-k-kic***ic*icicic***ic-k***ic****-k-kieicificicici(ie-kic-k****ic*-k-kif* 

* 

* Class addr methods 

★ 

* addr_)cey 

* addr_print 

* 

***★*★★*•★******************•***★*****★*★★*★*******★*★*********••*•*****★*********/ 



idl_routine void addr_key (address ) 
relational_addr address; 

( 

if (idl_string_size (address->state) == 0) 

( 

dpy_cstring (" ** No Street Address **"); 
dpy_eol ( ) ; 

} 

else 

( 

dpy_cstring (address->street ) ; 
dpy_eol ( ) ; 

) 

} 

/*= = = == = = = == = ======= = = = = ======= = = =;=:==== = = = = = = = == = = = = = ==== = = = == = = = = = = = === = = = =*/ 

idl_routine void addr_print (address , mode) 
relational_addr address; 
dpy_dmode mode ; 

( 

idl_transaction tr = idl_get_trans (address) ; 
boolean can_write = idl_trans_wri te_count ( tr )^ > 0; 

if (can_write) mode. exp and = 1; 

dpy_attr ( relational_addr, address , street , mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( IL) ; 

dpy_attr ( relational_addr, address, city, mode) ; 

if ( (mode . expand > 0 I i 

(idl_get_display (relational_addr, state) && 

(address->state ! = 0 && 

(idl_string_size (address->state) ) != 0)))) 

dpy_cstring ( " , " ) ; 

dpy_spacex( IL) ; 

dpy_attr ( relational_addr, address, state, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( IL) ; 
dpy_spacex(15L) ; 

dpy_attr ( relational_addr , address, zip, mode) ; 
dpy_eol ( ) ; 
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^**-k-kic-k-k*-icic-k****-k-k-k-k**it****ic*-k*-k-k***ic***icicteieteie**ie**ic*-kie-k-kie-k*ie-k********-k*ie-kie-k-i;-k 



* Class phone_number methods 

★ 

* phone_number_print 

* 

****************************l>r******»Tr**^******-Jt*')>r^***-*r*************-**********^ 



idl_routine void phone_number_print (pnumber/mode) 
relational_phone_number pnumber; 
dpy_dmode mode; 

{ 

dpy_attr { rela tional_phone_number, pnumber, number , mode) ; 
dpy_eol ( ) ; 
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y**************************************-************'**********'*'*:**'*'*****'******* 

* 

* Class proj_tuple methods 

* 

* proj_tuple_key 

* proj_tuple_print 

* initialize_proj_tuple 

* pro j_equal_to 

* pro j_less_than 

* proj_greater_than 

* 

****■*■*•**•*•**•***■*•**■**********•*■************■*•*■*************•*■•*•*■*■■*■*•*■*■**•****•*■*****■•*■* ! 
************************************************************************************* 



Class Proj_tuple Methods 

***********************-*************************************-******************** 



idl_routine void pro j_tuple_key (pro j_tuple) 
relational_pro j_tuple proj_tuple; 

{ 

dpy_integer (pro j_tuple->essn, 9) ; 
dpy_spacex ( 4L) ; 

dpy_integer (pro j_tuple->pro j_num, 3 ) ; 
dpy_spacex ( 4L) ; 

dpy_rational (proj_tuple->hours, 6) ; 
dpy_eol ( ) ; 



/*==========================================================================*/ 

idl_routine void proj_tuple_print (pro j_tuple, mode) 
relational_pro j_tuple pro j_tuple; 
dpy_dmode mode; 

{ 

idl_transaction tr = idl_get_trans (proj_tuple) ; 
boolean can_write = idl_trans_wri te_count ( tr) > 0; 

if (can_write) mode. expand = 1; 

dpy_attr ( relational^^ro j_tuple, proj_tuple, essn,mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( IL) ; 

dpy_attr ( relational_pro j_tuple, pro j_tuple , pro j_num, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( IL) ; 

dpy_attr ( relational_proj_tuple, proj_tuple, hours, mode) ; 
dpy_eol ( ) ; 



/*====================================================:======================*/ 

/* this function is called from create_tuple . It redefines the implementation 
for the class tuples method init ialize_tuples . Specifically, a new project 
tuple is created and given initial values (all of which are legal) . 

It returns a tuple to create_tuple which then allows the user to initialize 
this tuple with values. Each subtype of tuple needs to have a function 
like this. */ 

idl__routine relational_tuple initialize_pro j_tuple ( tuple_type) 
relational_tuple tuple_type; 

{ 

relational_proj_tuple new_tuple; 
idl_transaction tr = idl_get_trans ( tuple_type) ; 
string empty = idl_copy_string ( tr , " " ) ; 

new_tuple = idl_new ( tr, relational_pro j_tuple) ; 

/* must still assign legal values*/ 
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new_tuple->essn = 0; 
new_tuple->proj_num - 0; 
new_tuple->hours = 0.0; 

return idl_to { relational_tuple, new_tuple) ; 



/* this function returns true if rl tuple is equal to r2 tuple and 
returns false otherwise. */ 

idl_routine boolean pro j_equal_to {rl_tuple, r2_tuple, index) 
relational_pro j_tuple rl__tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple) ; 

switch (index) 

{ 

case 1 ; 

if (rl_tuple->essn == r2_tuple->essn) 
return true; 
else 

return false; 
break; 
case 2 : 

if { rl_tuple->pro j_num == r2_tuple->pro j_num) 
return true; 
else 

return false; 
break; 
case 3 : 

if ( rl_tuple->hours == r2_tuple->hours) 
return true; 
else 

return false; 
break; 
default : 

i dl_ra i s e { I DL_ERROR , 

"An ugly error has occured in pro j_equal_to" ) ; 

break; 



/*==========================================================================*/ 

/* this function returns true if rl tuple is less than r2 tuple and 
returns false otherwise. */ 

idl_routine boolean pro j_less_than { rl_tuple , r2_tuple, index) 
relational_pro j_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple ) ; 

switch (index) 

{ 

case 1: 

if ( rl_tuple->essn < r2_tuple->essn) 
return true; 
else 

return false; 
break; 
case 2 : 

if ( rl_tuple->pro j_num < r2_tuple->proj_num) 
return true; 



167 



else 

return false; 
break ; 
case 3 : 

if (rl_tuple->hours < r2_tuple->hours ) 
return true; 
else 

return false; 
break; 
default : 

idl_raise ( IDL_ERROR, 

"An ugly error has occured in pro j_less_than" In- 
break; 



/*==========================================================================*/ 

/* this function returns true if rl tuple is greater than r2 tuple and 
returns false otherwise. */ 

idl__routine boolean pro j_greater_than ( rl_tuple, r2_tuple , index) 
relational_pro j_tuple rl_tuple, r2_tuple; 
integer index; 

{ 

idl_transaction tr = idl_get_trans ( rl_tuple) ; 

switch (index) 

{ 

case 1 : 

if (rl_tuple->essn > r2_tuple->essn) 
return true; 
else 

return false; 
break; 
case 2 : 

if (rl_tuple->pro j_num > r2_tuple->proj_num) 
return true; 
else 

return false; 
break; 
case 3 : 

if (rl_tuple->hours > r2_tuple->hours ) 
return true; 
else 

return false; 
break; 
default : 

idl^raise (IDL^ERROR, 

"An ugly error has occured in pro j_greater_than" ) ; 

break; 

) 

) 
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/ 



★ ★★★★★★★★★Kr*itH:***********^************<r**********'*********i:H:*********Kr**** 



* Class cartl_result_tuple methods 

★ 

* cartl_result_tuple_key 

* cartl_result__tuple_print 

* initialize_cartl_resul_tuple 

* insert_cartl_resul t_tuples 

* 

********************************************************************************** 

Class Cart l_Result_Tuple Methods 

★ ★★★★★★★Hf*********************************************************************** 



idl_routine void cartl_resul t_tuple_key (cartl_tuple) 
relational_cartl_resul t_tuple cartl_tuple; 

{ 

idl_univ u; 

u = idl_to (idl_univ, cartl_tuple->person->lname) ; 
idl_vop (u, idl_univ, idl_key, (u)); 
dpy_spacex ( 4L) ; 

dpy_integer (cartl_tuple->essn, 9 ) ; 
dpy_spacex ( 4L) ; 

dpy_integer (cartl_tuple->pro j_num, 3 ) ; 
dpy_spacex(4L) ; 

dpy_rational (cartl_tuple->hours , 6 ) ; 
dpy_eol ( ) ; 



/*==========================================================================*/ 

idl_routine void cart l_result_tuple_print (cartl_tuple, mode) 
relational_cartl_resul t_tuple cartl_tuple; 
dpy_dmode mode; 

{ 

idl_transaction tr = idl_get_trans (cartl_tuple) ; 
boolean can_write = idl_trans_wri te_count ( tr ) > 0/ 

if (can_write) mode. expand = 1; 

mode . embed = 1 ; 

if (mode. expand >1) 

{ 

idl_top ( idl_any , idl_print , ( cartl_tuple, mode ) ) ; 

} 

dpy_attr ( relational_emp_tuple, cartl_tuple , person, mode) ; 
dpy_eol ( ) ; 
dpy__spacey (IL) ; 
dpy_eol ( ) ; 

dpy_attr ( relational_emp_tuple , cartl_tuple, phone, mode) ; 
dpy_eol ( ) ; 
dpy_spacey ( IL ) ; 
dpy_eol ( ) ; 

dpy^attr ( relational_emp_tuple, cartl_tuple , address , mode) ; 
dpy_eol ( ) ; 
dpy_spacey (IL) ; 

/* add widget in later when it is defined as something */ 

dPY— sttr ( relational_cartl_resul t_tuple, cartl_tuple, essn,mode) ; 
dpy_eol ( ) ; 
dpy^spacey (IL) ; 

dpy_attr ( relational_cartl_resul t_tuple, cartl_tuple, proj_num,mode) ; 
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dpy_eol { ) ; 
dpy_spacey (IL) ; 

dpy_aCtr (relational_cartl_resul t_tuple, cart l_tuple, hours, mode) ; 
dpy_eol { ) ; 



/ *==========================================================================^/ 

/* this function is called from create_tuple . It redefines the implementation 
for the class tuples method init ialize_tuples . Specifically, a new project 
tuple is created and given initial values (all of which are legal) . 

It returns a tuple to create_tuple which then allows the user to initialize 
this tuple with values. Each subtype of tuple needs to have a function 
like this. */ 

idl_routine relat ional_tuple initialize_cartl_resul_tuple (tuple_type) 
relational_tuple tuple_type; 

{ 

relational_cartl_resul t_tuple new_tuple; 
idl_transaction tr = idl_get_trans ( tuple_type) ; 
string empty = idl_copy_string ( tr, " " ) ; 

new^tuple = idl_new { tr, relational_cartl_result_tuple) ; 

/* must still assign legal values'^/ 

new_tuple->person = idl_new(tr,relational_person); 
new_tuple->person->fname = empty; 
new_tuple->person->mname = empty; 
new_tuple->person->lname = empty; 
new_tuple->person->bdate = empty; 
new_tuple->person->ssn = 0; 
new_tuple->person->spouse = empty; 

new_tuple->address = idl_new { tr , relational_addr ) ; 
new_tuple->address->street = empty; 
new_tuple->address->city = empty; 
new_tuple->address->state = empty; 
new_tuple->address->zip = empty; 

new_tuple->phone = idl_new{ tr, relational_phone_number ) ; 
new_tuple->phone->number = empty; 

/* new__tuple->widget needs to have widget defined first */ 

new_tuple->essn = 0; 
new_tuple->proj_num = 0; 
new_tuple->hours = 0.0; 

return idl_to {relational_tuple, new__tuple) ; 

} 



static relational_relation insert_cartl_result_tuples {rl, r2 , r3 ) 
relational_relation rl,r2,r3; 

{ 

relational_cartl_result_tuple new_tuple; 
relational_emp_tuple rell; 
relational_proj_tuple rel2; 
idl_transaction tr = idl_get_trans ( rl ) ; 

/* get rid of any tuples that may be in the resultant relation structure 
prior to insert the new result */ 

r3->tuples = idl_empty_linked { tr, relational_tuple ) ; 

idl_linked_for ( relational_tuple, rl->tuples, rl_tuple) 

{ 
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idl_linked_for ( relational_tuple, r2->tuples , r2_tuple) 

{ 

/* send message to get a new tuple created with valid default 
values. */ 

new_tuple = idl__to ( relational_cartl_resul t_tuple, 

idl_vop ( r3->tuple_type, relational_tuple, initialize_tuple, 

( r3 ->tuple_type) ) ) ; 

rell = idl_to (relational_emp_tuple, rl_tuple) ; 
rel2 = idl_to (relational_proj_tuple, r2_tuple) ; 

new_tuple->person->fname = rell->person->fname; 
new_tuple->person->mname = rell->person->mname; 
new_tuple->person->lname = rell->person->lname; 
new_tuple->person->bdate = rell->person->bdate; 
new_tuple->person->ssn = rel l->person->ssn; 

new_tuple->address->street = rell->address->street; 
new_tuple->address->city = rell ->address->city ; 
new_tuple->address->s tate = rel l->address^>state; 
new_tuple->address->zip = rell->address->zip; 

new_tuple->phone->number = rell->phone->number ; 

/* new_tuple->widget needs to have widget defined first */ 

new_tuple->essn = rel2->essn; 
new_tuple->proj_num = rel2->pro j_num; 
new_tuple->hours = rel2->hours; 

idl_insert_back (relational_tuple, r3 ->tuples , new_tuple ) ; 

} idl_end_for 
} idl_end_for 

return r3 ; 



} 
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y**^********************-T>r***********************Tlr***************<r************* 



* Class projectl_result:_t:uple methods 

★ 

* proj ectl_resul t__tuple__key 

* proj ectl_resul t_tuple_print 

* initialize_projectl_resul_tuple 

* insert_projectl_result_f Ids 

* 

*********★*★**★*★**★★*★★**★★*★★**★*★★★■*★★***★***★*■★★*★★*★•**★***•*★★**★*******★ j 
★ ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★Hr*********** 



Class Proj ectl_Result_Tuple Methods 

★ ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★It** 






idl_routine void projectl_resul t_tuple_key (proj ectl_resul t_tuple) 
relational_pro jectl_result_tuple pro j ectl_result_tuple ; 

{ 

dpy_rational (projectl_resul t_tuple->hours , 6 ) ; 
dpy_spacex(4L) ; 

dpy_integer (pro ject l_resul t_tuple->essn, 9 ) ; 
dpy_eol(); 



/ *==========================================================================*/ 

idl_routine void projectl_resul t_tuple_print (proj ectl_resul t^tuple, mode) 
relational_pro jectl_result_tuple projectl_result_tuple; 
dpy_dmode mode; 

{ 

idl_transaction tr = idl_get_trans (projectl_resul t_tuple) ; 
boolean can_write = idl_trans_wri te_count ( tr) > 0; 

if (can__write) mode. expand = 1; 

dpy_attr ( relational_pro ject l_result_tuple, pro ject l_result_tuple , hours /mode) ; 
dpy^eol ( ) ; 
dpy_spacey ( IL) ; 

dpy^attr (re la tional_pro ject l_result_tuple /Project l_result_tup le, essn/ mode) ; 
dpy_eol 0 / 



idl_routine relational_tuple initialize_pro j ectl_resul_tupl e ( tuple_type ) 
relational_tuple tuple_type; 

{ 

relational_projectl_resul t_tuple new_tuple; 
idl_transaction tr = idl_get_trans ( tuple_type) ; 

new_tuple = idl_new ( tr/ relational_projectl_resul t_tuple) ; 

/* must still assign legal values*/ 

new_tuple->essn = 0 ; 
new_tuple->hours = 0.0; 

return idl_to (relational_tuple/ new_tuple) ; 

) 



/ *==========================================================================*/ 

idl_routine relational_relation insert__projectl_resul t_f Ids (rel , result_rel) 
relational_relation rel , result_rel ; 

{ 

relat ional_projectl_resul t_tuple new_tuple; 
relational_proj_tuple rell; 
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idl_transact:ion tr = idl_get_trans ( rel ) ; 

result:_rel->t:uples = idl_empt:y_linlced (tr, relational_tuple) ; 

new_tuple = idl_new ( tr, relat:ional_pro ject l_result_tuple) ; 

/* must still assign legal values*/ 



idl_linked__for ( relational_tuple, rel->tuples, rl_tuple) 

{ 

/* send message to get a new tuple created with valid default 
values. */ 

new_tuple = idl_to ( relational_pro jectl_result_tuple , 
idl_vop ( resu 1 t_rel - 

>tuple_type, relational_tuple, initial i ze_tuple , ( result_rel ->tuple_type) ) ) 

rell = idl_to ( relational_proj_tuple, rl_tuple) ; 

new_tuple->essn = rell->essn; 
new_tuple->hours = rell->hours; 

idl_insert_back ( relational_tuple, result_rel-> tuples , new_tuple) ; 

} idl_end_for 
return result_rel; 

) 
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★ 

* General functions to display a character string and an integer 

* 

* exit_action 

* char_screen 

* integer_screen 

* 

★ *★★★★★***★**********★****■*★***★★★★***■*★★***★**★**■★****★*★★★***★★★★★*★**★*★*★ 



/* called by char_screen and integer_screen to exit the pop up window */ 

idl_routine void exi traction ( i ) 
integer i; 

{ 

dpy_quit { ) ; 



/*==========================================================================*/ 

/* display the string s on a pop-up screen using dpy_active (char_screen, s ) 
Note: the browser restricts s to 80 characters */ 

idl_routine void char_screen (s, x,y) 
string s; 
integer x,y; 

{ 

dpy_open { "Display St ring" , true) ; 
dpy^open {" format" , true) ; 

brw^cmd ( "Exit" , "exit this screen" , exi traction, 0, BRW_SCREEN) ; 

dpy_eol(); 

dpy_spacey (2 ) ; 

dpy_eol ( ) ; 

dpy_cstring ( s) ; 

dpy^spacey (2 ) ; 

dpy_eol { ) ; 

dpy^close ( ) ; 

brw_input_area (y-3 , true) ; 
dpy_close { ) ; 
dpy_boxed (X/y) ; 



/*==========================================================================*/ 

/* display the integer s on a pop-up screen */ 
idl_routine void integer_screen (s,x,y ) 
integer s; 
integer x,y; 



dpy_open {"Display Integer" , true) ; 
dpy_open ( " format" , true ) ; 

brw_cmd ( "Exit" , "exit this screen" , exi traction, 0 , BRW_SCREEN) ; 

dpy_eol ( ) ; 

dpy_spacey (1 ) ; 

dpy^eol ( ) ; 

dpy_integer ( s, 5) ; 

dpy^spacey (2 ) ; 

dpy_eo 1 0 ; 

dpy_close ( ) ; 

brw_input_area (y-3 , true) ; 
c^py— close ( ) ; 
dpy^boxed (x,y ) ; 
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* 

* Binding and Initialization 

* 

★ ****-jt**-*********'******************'**************************'*:********'*''*'*****/ 



idl_def ine_ops relational_opbind ( ) 

{ 

idl_bind_root ( relational ) ; 

idl_bind ( "database_key" , database_key ) ; 
idl_bind( "database_print" , databage_print ) ; 
idl_bind ( "create_relation" , create_relation) ; 

idl_bind ( "relation_key" , relation_key ) ; 
idl_bind( "relation _print" , relation_print) ; 
idl_bind( "create_tuple" , create_tuple) ; 

idl_bind( "ck_union_compatabil ity " , ck_union_compatability) ; 

idl_bind ( "union_op" ,union_op) ; 
idl_bind ( "cart_prod_op" , cart jrod_op) ; 
idl_bind ( "set_dif f_op" , set_dif f_op) ; 
idl_bind ( "pro ject_op" , pro ject_op) ; 
idl^bind ( "select_op" ^ select_op) ; 

idl_bind ( "equal_to" , equal_to) ; 
idl_bind ( "less_than" , less_than) ; 
idl_bind ( "greater_than" , greater_than) ; 

idl_bind ( "ini tial ize_tuple" , initialize_tuple) ; 
idl_bind( "insert_f ields" , insert_f ields) ; 
idl_bind ( "insert_tuples" , insert_tuples ) ; 

idl_bind ( "name_key" , name_key ) ; 
idl_bind( "name_print" , name_print) ; 

idl_bind ( "emp_tuple_key " , emp_tuple_key) ; 

idl_bind( "emp_tuple_print " , emp_tuple_print ) ; 

idl_bind ( "emp_equal_to" , emp_equal_to) ; 

idl_bind ( "emp_less_than" / emp_less_than) ; 

idl_bind ( "emp_greater_than" , emp_g reate r_than) ; 

idl_bind( " initial ize_emp_tuple" , ini tialize_emp_tuple) ; 

idl_bind ( "person_key" , person_key) ; 
idl_bind ( "person_print" ,person_print) ; 

idl__bind ( "addr_key" , addr_key) ; 
idl_bind ( "addr_print" , addr_print ) ; 

idl_bind ( "phone_nuraber_print" , phone_number_print ) ; 

idl_bind ( "pro j_tuple_key" , pro j_tuple_key ) ; 

idl_bind( "proj_tuple_print" , pro j_tuple_print ) ; 

idl_bind( "proj_equal_to" , proj_equal_to) ; 

idl_bind ( "pro j_less_than" , pro j_lesg_than) ; 

idl_bind ( "pro j_greater_than" ^ proj_greater_than) ; 

idl_bind ( "ini tial ize_proj_tuple" , ini tial i ze_proj_tuple) ; 



idl_bind ( "cartl_regul t_tuple_key" , cartl_regul t_tuple_key ) ; 
idl_bind ( "cartl_regul t_tuple_print" , cartl_regul t_tuple_print ) ; 
idl_bind ( " initialize_cartl_regul_tuple" , initialize_cartl_regul_tuple) ; 
idl_bind( "ingert_cartl_regult_tupleg" , ingert_cartl_regult_tupleg) ; 



idl_bind ( "projectl_regul t_tuple_key " , proj ectl_regul t_tuple_key ) ; 
idl_bind ( "projectl_regult_tuple_print" , proj ectl_regul t_tuple_print ) ; 
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idl_bind( ''inicialize_projeccl_resul_cuple" , inicialize_projectl_resul_cuple) 
idl_bind( "inserC_projectl_resulc_flds" , insert_projectl_resulc_f Ids) ; 



} 
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APPENDIX D: A SAMPLE R/OODBMS DATABASE ASCH CLUSTER FILE 



-- Generated by IDB System Version 1.1 
@[ cid < 16#e6842701 16#00000000 16#00000036 > / 
lid_seed 3566 ]@ 
x355'^ 

xl: 1063© name [ name 1064© "person" ] 

x2 : 1065© name [ name 1066© "address" ] 

x3 : 1067© name[ name 10 68© "phone" ] 

x4 : 106 9© name [ name 1070© "widget" ] 

x5 : 12 57© name [ name 12 67© "person" ] 

x6: 1259© name [ name 1266© "addr" ] 

x7 : 1261© name [ name 1268© "phone_number" ] 

x8: 1272© name [ name 1275© "idl_univ" ] 

x9 : 1072© person [ fname xl76'^ ; mname xl77^^ ; Iname xl78^ ; bdate xl79^ ; ssn 
122121212 ; spouse 3015© "Lisa" ; sptr nil ] 

xlO: 1074© addr [ street xl81'^ ; city xl82'^ ; state xl83'^ ; zip xl84"^ ] 
xll: 1075© phone_number [ number xl86'^ ] 

xl2 : 1076© emp_tuple[ person x9'^ ; address xlO^ ; phone xll^ ; widget nil ] 
xl3 : 1078© person [ fname x201'^ ; mname x202"^ ; Iname x203'^ ; bdate x204^ ; ssn 
110121212 ; spouse 3024© "Stephanie" ; sptr nil ] 

xl4: 1080© addr[ street x206'^ ; city x207^ ; state x208^^ ; zip x209^^ ] 
xl5 : 1081© phone_number [ number x211'^ ] 

xl6: 1082© emp_tuple[ person xl3'^ ; address xl4^ ; phone xl5^ ; widget nil ] 
xl7 : 1084© person[ fname x226^^ ; mname x227^ ; Iname x228'^ ; bdate x229^^ ; ssn 
220121212 ; spouse 3033© "Joan" ; sptr nil ] 

xl8: 1086© addr[ street x231'^ ; city x232^ ; state x233^ ; zip x234^^ ] 
xl9: 1087© phone_number [ number x236'^ ] 

x20: 1088© emp_tuple[ person xl7^ ; address xl8^^ ; phone xl9^ ; widget nil ] 
x21: 1090© person[ fname x251'^ ; mname x252'^ ; Iname x253'^ ; bdate x254'^ ; ssn 
120926190 ; spouse 3040© "Karin" ; sptr nil ] 

x22: 1094© addr [ street x256^^ ; city x257^ ; state x258^' ; zip x259"^ ] 
x23 : 1095© phone_number [ number x261'^ ] 

x24: 1096© emp_tuple[ person x21^^ ; address x22'^ ; phone x23'^ ; widget nil ] 
x25: 1098© person [ fname x276^ ; mname x277^ ; Iname x278^ ; bdate x279^ ; ssn 
123456789 ; spouse 1097© "" ; sptr nil ] 

x26: 1102© addr [ street x281^ ; city x282^^ ; state x283'^ ; zip x284^^ ] 
x27 : 1105© phone_number [ number x286^^ ] 

x28: 1106© emp_tuple[ person x25'^ ; address x26^^ ; phone x27^^ ; widget nil ] 
x29: 1348© person [ fname x301^ ; mname x302^^ ; Iname x303'^ ; bdate x304'^ ; ssn 
991221234 ; spouse 3053© "Lesa" ; sptr nil ] 

x30: 1349© addr [ street x306'^ ; city x307'^ ; state x308^ ; zip x309"^ ] 
x31: 13 50© phone_number [ number x311'^ ] 

x32: 1347© emp_tuple [ person x29^ ; address x30^ ; phone x31^ ; widget nil ] 
x33 : 1354© person! fname 1355© "" ; mname 1356© "" ; Iname 1382© "" ; bdate 1358© 
"" ; ssn 0 ; spouse 1359© "" ; sptr nil ] 

x34: 1360© addr [ street 1361© "" ; city 1362©‘ "" ; state 1363© "" ; zip 1364© "" ] 
x35: 1365© phone_number [ number 1366© "" ] 

x3 6: 13 53© emp_tuple[ person x3 3^^ ; address x34^^ ; phone x3 5^^ ; widget nil ] 
x37 : 1107© relation! relation_name 1108© "rl" ; att ribute_names x38^^ ; 
attribute_types x39'^ ; tuples 1110© < xl2'^ xl6'^ x20^^ x24'^ x28^^ x32'^ > ; tuple_type 



X36'" 


; Icey 


x353" ] 






x38: 


1113© 


< xl”^ x2^ x3"^ x4^^ > 






x39 : 


1254© 


< x5^ x6"^ x7^ x8^^ > 






x40 : 


1239© 


person! fname 1240© "Nancy" 


; mname 3059© "J." 


; Iname 1241© "McClellan" 



; bdate 3060© "14 Feb 57" ; ssn 990124444 ; spouse 1238© "" ; sptr nil ] 

x41: 1242© addr! street 3062© "2331 Long St." ; city 3063© "Monterey" ; state 3064© 

"CA" ; zip 3065© "93940" ] 

x42 : 1243© phone_number ! number 3 061© "{203) 999-9991" ] 

x43 : 1244© emp_tuple! person x40'^ ; address x41'^ ; phone x42^ / widget nil ] 
x44 : 1221© person! fname 3 06 6© "Leonard" ; mname 30 67© "H." ; Iname 1222© "Tharpe" 

; bdate 3068© "12 Aug 58" ; ssn 110121212 ; spouse 3069© "Stephanie" ; sptr nil ] 
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city 2779@ "Monterey'' ; state 



x45: 12230 addr [ street 30710 "432 Caldwell Drive" 

30720 "CA" ; zip 30730 "93940" ] 
x46: 12240 phone_number [ number 30700 "(408)452-1234" ] 

x47 : 12250 emp_tuple[ person x44^ ; address x45^^ ; phone x46^^ / widget nil ] 
x48: 12270 person [ fname 30740 "David" ; mname 30750 "M." ; Iname 12280 "Nash" ; 
bdate 30760 "21 Jul 65" ; ssn 23551324 ; spouse 30770 "Tammy" ; sptr nil ] 
x49: 12290 addr [ street 30790 "2112 Leidig Circle" ; city 27780 "Monterey" ; state 
30800 "CA" ; zip 30810 "93940" ] 
x50 
x51 
x52 



x53 

x54 

x55 

x56 



12300 phone_number [ number 30780 "(408)123-4567" ] 

12 310 emp_tuple[ person x48'^ ; address x49'^ ; phone x50^^ ; 
13680 person! fname 13690 "" ; mname 13700 "" ; Iname 13710 
ssn 0 ; spouse 13730 "" ; sptr nil ] 

137 40 addr [ street 13750 "" ; city 137 60 "" ; state 13770 "" 
13790 phone_number [ number 13800 



widget nil ] 

"" ; bdate 13720 

; zip 13780 "" ] 



13670 emp_tuple[ person x52^^ ; address x53' 
11320 relation! relation_name 11330 "r2" ; 
att ribute_types x39^^ ; tuples 11350 < x43^^ x47'^ 
11370 "person -> ssn" ] 



‘ ; phone x5 4^^ ; widget nil 
attribute_names x3 8'^ ; 
x51^^ > ; tuple_type x55^^ ; 



key 



x57 

x58 

x59 

x60 

x61 



12790 name! name 12880 "person" ] 
12810 name! name 12890 "addr" ] 

12830 name! name 12900 "phone__number 
12850 name! name 12910 "diff_type" ] 
11390 person! fname 11400 "Tim" 



mname 30890 " J . " 



bdate 30900 "4 Jul 62" ; ssn 22121212 ; spouse 11380 



Iname 11410 
sptr nil ] 



"Kelly" 



x62 : 11420 addr! street 11430 "345 Bergin" ; city 11440 "Monterey" ; state 11450 
"CA" ; zip 30920 "93940" ] 

x63 : 11460 phone_number ! number 3 0910 "(408)123-4 567" ] 

x64: 11480 emp_tuple! person x61'^ ; address x62^' ; phone x63^ ; widget nil ] 
x65: 11500 person! fname 11510 "Ronald" ; mname 11520 "L." ; Iname 11530 "Spear" 
; bdate 30820 "29 Dec 62" / ssn 120926190 ; spouse 30830 "Karin" ; sptr nil ] 
x66: 11540 addr! street 30850 "397B Ricketts Road" ; city 30860 "Monterey" ; state 
30870 "CA" ; zip 30880 "93940" ] 



x67 

x68 

x69 
// // 

x7 0 
x71 
x7 2 
x7 3 



11550 phone__number ! number 30840 "(408)375-8619" ] 



11560 emp_tuple! person x65^ ; address x66' 
13840 person! fname 13850 "" ; mname 13860 ' 
ssn 0 ; spouse 13890 "" ; sptr nil ] 

13900 addr! street 13910 "" ; city 13920 "" 
13950 phone_number ! number 13960 "" ] 

13830 emp_tuple! person x69'^ ; address x70' 
11570 relation! relat ion_name 11580 "r3" ; 



phone x67'^ ; widget nil ] 

; Iname 13870 "" ; bdate 13880 



state 13930 



zip 13940 



attribute_types 12760 < xSl' 



tuple_type x72 
x7 4 



x58'" x59'" x60" 
"person -> ssn" 



x7 5 
x7 6 
x77 
x78 
x7 9 
x80 
x81 
X82 
x83 
x84 
x85 
x8 6 
x87 
x88 
x89 
x90 
x91 
x92 
x93 
x94 
x95 
ssn 0 
x96 
x97 
x98 



key 11620 

11630 name! name 11640 "person -> fname" 

11650 name! name 11660 "person -> mname" 

11670 name! name 11680 "person -> Iname" 

11690 name! name 11700 "person -> bdate" 

11710 name! name 11720 "person -> spouse 

11730 name! name 11740 

11750 name! name 11760 

11770 name! name 11780 

11790 name I name 11800 "addr 

11810 name! name 11820 "phone -> 

13100 name! name 13300 "string" 

13120 name! name 13310 "string" 

13140 name! name 13320 "string" 

13160 name! name 13330 "string" 

13180 name! name 13400 "integer" 

13200 name! name 13350 "string" 

13220 name! name 13360 "string" 

13240 name! name 13370 "string" 

13260 name! name 13380 "string" 

13280 name! name 13390 "string" 

11830 "" 

11840 person! fname x94^ ; mname x94 
spouse x94^ ; sptr nil 



■ ; phone x71^^ ; widget nil ] 
attribute_names x38'^ ; 
tuples 11600 < x64^^ x68'^ > ; 



'addr -> street" 
'addr -> city" ] 
'addr -> state" ] 
-> zip" ] 
number" 



Iname 11850 "Larson" ; bdate x94^ 



11860 addr! street x94'" ; city x94'' 

11870 phone_number ! number x94^ ] 

11880 emp_tuple! person x95'^ ; address x96 



state x94'^ ; zip x94'^ ] 

phone x97^ ; widget nil ] 
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Iname 11910 "Johnson" ; bdate x99^ 



state x99' 



; zip x99" 
phone xl02' 



widget nil 



bdate 



x99; 11890 "" 

xlOO; 11900 person! fname x99^^ ; mname x99 
; ssn 0 ; spouse x99^ ; sptr nil ] 
xlOl: 11920 addr [ street x99^ ; city x99^ 
xl02: 11930 phone_number [ number x99"" ] 
xl03: 11940 emp_tuple[ person xlOO'" ; address xlOl 
xl04: 11950 "" 

xl05: 11960 person! fname xl04'^ ; mname xl04^ ; Iname 11970 "Lombardo" 
xl04"" ; ssn 0 ; spouse xl04^ ; sptr nil ] 
xl06: 11980 addr! street xl04^ ; city xl04'^ ; state xl04 
xl07 : 11990 phone_number ! number xl04^ ] 

xl08: 12000 emp_tuple! person xlOS'^ ; address xl06"^ ; phone xl07^ ; widget nil 
xl09: 14400 person! fname 14410 "" ; mname 14420 "" ; Iname 14430 
"" ; ssn 0 ; spouse 14450 "" ; sptr nil ] 

xllO: 14460 addr! street 14470 "" ; city 14480 "" ; state 14490 "" 
xlll: 14510 phone_number ! number 14520 "" ] 

xll2: 14390 emp_tuple! person xl09^ ; address xllO^ ; phone xlll 
xll3: 12010 relation! relat ion_name 12020 "test2" ; att ribute_names xll4'' 
attribute_types xll5^ ; tuples 12040 < x98^ xl03^ xl08^ > ; tuple_type xll2 
12060 "person -> ssn" ] 



zip xl04"" ] 



] 

bdate 14440 
zip 14500 "" ] 
widget nil ] 
key 



12070 < x74" x75^" x76^ x77^ x78^" xl 9^ x80 
13070 < X84" x85^ x86^ x87^ x88^ x89" x90 
14260 person! fname 14270 "" ; mname 14280 "" 
ssn 0 ; spouse 14310 "" ; sptr nil ] 

14320 addr! street 14330 "" ; city 14340 "" ; 
14370 phone_number ! number 14380 "" ] 

14250 emp_tuple! person xll6^ ; address xll7 
12080 relation! relat ion_name 12090 "TEMPI" 
att ribute_types xll5'^ ; tuples 12110 < x98^ 

; key 12130 "person -> ssn" ] 

12950 name! name 13030 "person" ] 

12970 name! name 13040 "addr" ] 

12990 name I name* 13050 "phone_number 
13010 name! name 13060 "idl_univ" 

12150 person! fname 30930 "James" 



xll4 

xll5 

xll6 

// 0t « 

Xll7 

Xll8 

xll9 

xl20 



xl21 

xl22 

xl23 

xl24 

Xl25 



x81^ x82^" x83^" 
x91^ X92'" x93^^ 

' ; Iname 14290 

' state 14350 "' 



; bdate 14300 
zip 14360 "" 1 
widget nil ] 



xl03' 



; phone xll8^ 
attribute_names xll4' 
xlOO'" x64^ > ; tuple_type xll9' 



mname 3 0940 "S . " 



bdate 30950 "12 Jan 85" ; ssn 550121212 ; spouse 12140 



Iname 12160 "Baumann" 
sptr nil ] 



city 27800 "Fayetteville" 



Xl26: 12170 addr! street 30970 "41112 Lost Lane" 
state 30980 "NC" ; zip 30990 "32212" ] 

12180 phone_number! number 30960 "(231)222-3333" ] 

12190 emp_tuple! person xl25^^ ; address xl26^^ ; phone xl27^ 

13980 person! fname 13990 "" ; mname 14000 "" ; Iname 14010 " 
ssn 0 ; spouse 14030 "" ; sptr nil ] 

14040 addr! street 14050 "" ; city 14060 "" ; state 14070 "" 

14090 phone_number ! number 14100 "" ] 

13970 emp_tuple! person xl29^ ; address xl30'" ; phone xl31^ 

12320 relation! relation_name 12330 "r4" ; attribute_names x38^ 
attribute_types 12920 < xl21^ xl22^ xl23'^ xl24^ > ; tuples 12350 < xl28' 

> ; tuple_type xl32'" ; key 12370 "person -> ssn" ] 

xl34: 14120 person! fname 14130 "" ; mname 14140 "" ; Iname 14150 "" ; bdate 14160 
"" ; ssn 0 ; spouse 14170 "" ; sptr nil ] 

14180 addr! street 14190 "" ; city 14200 "" ; state 14210 "" 

14230 phone_number ! number 14240 "" ] 

14110 emp_tuple! person xl34^^ ; address xl35^ ; phone xl36' 

12450 relation! relat ion_name 12460 "r5" ; at tribute_names x38'' 



xl27 

xl28 

xl29 

n It 

xl30 

xl31 

Xl32 

Xl33 



tuples 12480 < x43"^ > ; tuple_type xl37'^ ; key 12500 "person 



xl35 
Xl36 
Xl37 
xl38 

attribute_types x39 
-> ssn" ] 

xl39: 15010 name! name 15180 "Employee SSN" ] 

15030 name! name 15190 "Project Number" ] 
15050 name! name 15200 "Hours Worked" ] 
15100 name! name 15210 "integer" ] 

15120 name! name 15220 "integer" ] 

15140 name! name 15230 "rational" ] 

15260 proj_tuple! essn 120926190 



; widget nil ] 
; bdate 14020 

zip 14080 "" ] 

widget nil ] 

x47^^ x51'" 



zip 14220 "" 
widget nil 



xl40: 
Xl41; 
Xl42: 
Xl43 : 
Xl44 : 
Xl45: 
Xl4'-: 
Xl47 : 
Xl48: 
Xl49: 



15290 proj_tuple! essn 999999999 
15320 proj_tuple! essn 123456789 
15350 proj_tuple! essn 987654321 
14970 proj_tuple! essn 



proj_num 2 ; 
proj^num 1 ; 
proj_num 2 ; 
proj_num 30 
proj^num 0 ; hours 0 



hours 10, 
hours 45. 
hours 51 , 
: hours 4. 
.0 ] 
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Xl50: 

xl40'^ 

xl46" 

xl51 

xl52 

xl53 

xl54 

xl55 

xl56 

xl57 

xl58 

xl59 

xl60 

xl61 



14900 

xl41" 

xl47'^ 

15540 

15560 

15580 

15600 

15620 

15640 

15680 

15710 

15740 

15470 

15400 



relation [ relation_name 14950 "ptl" ; 
> ; attribute_types 15070 < xl42"^ xl43" 



attribute^names 14980 
xl44"^ > / tuples 14940 



< xl39" 

< xl45^ 



xl48^^ > ; tuple_type xl49^ ; key 14960 "essn, pro j_num" 
name [ name 15750 "Employee SSN" ] 

"Project Number" ] 

"Hours Worked" ] 

"integer" ] 

"integer" ] 

"rational" ] 



name [ name 15760 
name [ name 15780 
name[ name 15790 
name[ name 15800 
namei name 15810 
proj_tuple[ essn 550926190 
proj_tuple[ essn 666666666 
proj_tuple[ essn 123456789 



; hours 34.4 
hours 15.0 ] 
hours 24.0 ] 



proj_num 23 
proj_num 2 
proj_num 1 

proj_tuple[ essn 0 ; proj_num 0 ; hours 0.0 
relation [ relation_name 15450 "pt2" ; attribute_names 15480 

xl55^ xl56"^ > ; tuples 15440 
"essn, proj_num" ] 



xl52^ 


X153'" 


> ; attribute_types 15510 < 


X154'" 


X158'" 


xl59" 


> ; tuple_i 


type xl60^^ ; key 


15460 


xl62 : 


16180 


name [ 


name 


16580 


" Person" 


] 


Xl63 : 


16200 


name [ 


name 


16590 


"Address" 


] 


Xl64: 


16220 


name [ 


name 


16600 


"Phone" ] 




Xl65: 


16240 


name [ 


name 


16610 


"Widget" 


] 


Xl66: 


16260 


name [ 


name 


16550 


"Employee 


SSN" 


Xl67 : 


16280 


name [ 


name 


16570 


"Project Number 


Xl68 : 


16300 


name [ 


name 


16560 


"Hours Worked" 


Xl69: 


16350 


name [ 


name 


16620 


"person" 


) 


Xl70: 


16370 


name [ 


name 


16630 


"addr" ] 




xl71: 


16390 


name [ 


name 


16640 


"phone_number" 


Xl72 : 


16410 


name [ 


name 


16650 


"idl_univ‘ 


'' ] 


Xl73 : 


16430 


name [ 


name 


16660 


"integer" 


] 


xl74: 


16450 


name [ 


name 


16670 


"integer" 


] 


Xl75: 


16470 


name [ 


name 


16680 


" rational ‘ 


" ] 


Xl76: 


30120 


"Mathew" 








Xl77 : 


30130 


"James" 








Xl7 8 : 


10730 


"Rothlisberger" 






Xl79: 


30140 


"23 Feb 60' 


ft 






Xl80: 


32100 


person [ fname xl7 6'^ ; mname xl77' 



< xl51" 

< xl57" 



Xl82 : 
Xl83 : 
Xl84: 
Xl85: 
Xl8 6; 
Xl87 : 
Xl88 : 

nil ; 
xl89: 



122121212 ; spouse 32080 "" ; sptr nil ] 
xl81: 30170 "231 Bergen" 

30180 "Monterey" 

30190 "CA" 

30200 "93940" 

32110 addr[ street xl81^ ; city xl82" 
30160 " (408) 375-1234" 

3 2120 phone_number [ number xl8 6"^ ] 

32090 cartl_result_tuple [ person xl80'' 
essn 550926190 ; proj_num 2 ; hours 10.0 
32250 person [ fname xl76^ ; mname xl77^ 
122121212 ; spouse 32230 "" ; sptr nil ] 
xl90: 32260 addr[ street xlSl'^ ; city xl82'^ 
xl91: 32270 phone_number [ number xl86^ ] 
xl92: 32240 cart l_resul t_tuple [ person xl89^^ ; 
nil ; essn 999999999 ; proj_num 1 ; hours 45 
xl93: 32400 person[ fname xl76'^ ; mname xl77 
122121212 ; spouse 32380 "" ; sptr nil ] 
xl94: 32410 addr [ street xl81'^ ; city xl82'^ 

3 2420 phone_number [ number xl86'^ ] 

32390 cartl_resul t_tuple [ person xl93^ ; 
essn 123456789 ; proj_num 2 ; hours 51 
32550 person ( fname xl7 6"^ ; mname xl77 
122121212 ; spouse 32530 "" ; sptr nil ] 
xl98: 32560 addr[ street xl81^ ; city xl82^ 

3 2 570 phone_number [ number xl86"^ ] 



Iname xl78^ 



state X183'' 



bdate xl79^ ; ssn 



zip xl84^ ] 



address xl85'^ ; phone xl87' 



xl95: 
xl96: 
nil ; 
X197: 



Xl99: 



] 

; Iname xl78^ 

state xl83'^ ; 

address xl90^^ 

2 ] 

; Iname xl78^ 

state xl83'^ ; 

address xl94"^ 

5 ] 

; Iname xl78' 
state xl83^ ; 



bdate xl79 



; widget 
; ssn 



x200: 


32540 


cartl_result_tuple [ ; 


nil ; 


essn 


987654321 ; proj_num 


x201 : 


30210 


"Leonard" 


X202 : 


30220 


"H. " 


x203 : 


10790 


"Tharpe" 


x204 : 


30230 


"12 Aug 58" 



hours 4 



address xl98' 

.0 ] 



zip xl84'^ ] 

phone xl91'^ ; widget 

; bdate xl79^ ; ssn 

zip xl84^^ ] 

phone xl95"^ ; widget 

; bdate xl79^ ; ssn 

zip xl84^^ ] 

phone xl99'^ ; widget 
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x205: 32700 
110121212 ; 



X206 

x207 

x208 

x209 

x210 

x211 

x212 

x213 

nil 

x214 



30260 

30270 

30280 

30290 

32710 

30250 

32720 

32690 

essn 

32850 



110121212 ; 
x215: 32860 
x216: 32870 
x217: 32840 
nil ; essn 
x218: 33000 
110121212 ; 
x219: 33010 
X220: 33020 
x221: 32990 



nil ; 
x222 ; 



essn 

33150 



110121212 ; 
x223: 33160 
X224: 33170 
x225: 33140 



nil ; 
x226; 
x227 : 



essn 

30300 

30310 



x228: 10850 
x229: 30320 
x230: 33300 
220121212 ; 
x231: 30350 



x23 2 : 
x233 : 
x234: 
x235 ; 
x236: 
x237; 



30360 

30370 

30380 

33310 

30340 

33320 



x238: 33290 
nil ; essn 
X239: 33450 
220121212 ; 
x240; 33460 
x241; 33470 
x242: 33440 
nil ; essn 
x243: 33600 
220121212 ; 
x244: 33610 
x245: 33620 
x246: 33590 
essn 
33750 
220121212 ; 
X248: 33760 
x249: 33770 
x250: 33740 
essn 
10910 
10920 
10930 
30390 
33900 



nil ; 
x247: 



nil ; 
x251: 
x252: 

X253 : 
x254: 
x255: 
120926190 



person [ fname x201'^ ; mname x202'^ 
spouse 32680 "" ; spCr nil ] 

"432 Caldwell Drive" 

"Monterey" 

"CA" 

"93940" 

addr [ street x206'^ ; city x207^ ; 
" (408)452-1234" 
phone_number [ number x211'^ ] 
cartl_resul t_tuple [ person x205"^ ; 
550926190 ; proj_num 2 ; hours 10. 
person [ fname x201^^ ; mname x202'^ 
spouse 32830 "" ; sptr nil ] 
addr[ street x206^^ ; city x2 07'^ ; 
phone_number [ number x211'^ ] 
cartl__result_tuple( person x214'^ ; 
999999999 ; proj_num 1 ; hours 45. 
person [ fname x2 01'^ ; mname x202'^ 
spouse 32980 "" ; sptr nil ] 
addr[ street x206'^ ; city x207'^ ; 
phone__number [ number x211'^ ] 
cartl_resul t_tuple [ person x218^^ ; 
123456789 ; proj_num 2 ; hours 51. 
person [ fname x201^^ ; mname x202^^ 
spouse 33130 "" ; sptr nil ] 
addr[ street x206^^ ; city x207^ ; 
phone_number [ number x211^ ] 
cartl_result_tuple [ person x222'^ ; 
987654321 ; proj_num 30 ; hours 4. 
"Charles" 

" L . " 

"Baumann" 

"23 Jun 54" 

person [ fname x22 6'^ ; mname x227^ 
spouse 33280 "" ; sptr nil ] 
"12345 General Lane" 

"Ft Bragg" 

"NC" 

"16234" 

addr[ street x231^ ; city x23 2^^ ; 
" (122)324-9876" 
phone_number [ number x236^ ] 
cartl__resul t_tuple [ person x230'^ ; 
550926190 ; proj_num 2 ; hours 10. 
person [ fname x226^ ; mname x227^ 
spouse 33430 "" ; sptr nil ] 
addr[ street x231"^ ; city x232^ ; 
phone__number [ number x2 3 6"^ ] 
cartl_result__tuple [ person x239'^ ; 
999999999 ; proj_num 1 ; hours 45. 
person [ fname x226^ ; mname x227^ 
spouse 33580 "" ; sptr nil ] 
addr[ street x2 31^ ; city x23 2'^ ; 
phone_number [ number x236^ ] 
cartl_result_tuple [ person x243^ ; 
123456789 / proj_num 2 ; hours 51. 
person [ fname x22 6^^ ; mname x227^ 
spouse 33730 "" ; sptr nil ] 
addr[ street x231^ ; city x232^ ; 
phone_number [ number x2 3 6'^ ] 
cartl_resul t_tuple [ person x247^ ; 
987654321 ; proj_num 30 ; hours 4. 
"Ronald" 

"L. " 

"Spear" 

"29 Dec 62" 

person [ fname x251'^ ; mname x252^^ 
spouse 33880 "" ; sptr nil ] 



; Iname x203 



state x208^ 



address x210'^ 
0 ] 

; Iname x203 

state x208^ 

address x215'^ 
2 ] 

; Iname x203 

state x208"^ 

address x219^^ 
5 ] 

; Iname x203 

state x208^^ 

address x2 23'^ 
0 ] 



; Iname x228 



state x233' 



address x2 3 5'^ 
0 ] 

; Iname x228 

state x233^^ 

address x240^ 
2 ] 

; Iname x228 

state x233'^ 

address x2 44^^ 
5 ] 

; Iname x228 

state x233^^ 

address x248^ 
0 ] 



; Iname x253 



; bdate x204 



; zip x209^^ ] 

; phone x212^ ; 

; bdate x204^ 
; zip x209"^ ] 

; phone x216^^ ; 
^ ; bdate x204^ 
; zip x209'^ ] 

; phone x220"^ ; 

; bdate x20 4'" 
; zip x209"^ ] 

/ phone x224^ ; 



; bdate x229 



; zip x234^ ] 

; phone x23 7'^ ; 

; bdate x22 9'' 
; zip X234-" ] 

; phone x2 41'^ ; 
^ ; bdate x229^ 
; zip x234'" ] 

; phone x24 5"^ ; 

; bdate x229^ 
; zip x234" ] 

; phone x249^ ; 



; bdate x25 4 



; ssn 



widget 
; ssn 

widget 
; ssn 

widget 
; ssn 

widget 
; ssn 



widget 
; ssn 

widget 
; ssn 

widget 
; ssn 

widget 
; ssn 
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x256: 30420 "397B RickeCts Road" 
x257: 30430 "Monterey" 
x258: 30440 "CA" 
x259: 30450 "93940" 

x260: 33910 addr [ street x256^ ; city x257^ ; state x258^ ; 

x261: 30410 "(408)375-8619" 

x262: 33920 phone_number [ number x261^ ] 

x263 : 33890 cart l_result_tuple [ person x255'^ ; address x260^ ; 
nil ; essn 550926190 ; proj_num 2 ; hours 10.0 ] 
x264: 34050 person[ fname x251"^ / mname x252"^ ; Iname x253^ 
120926190 ; spouse 34030 "" ; sptr nil ] 

x265: 34060 addr[ street x256^ ; city x257"^ ; state x258^ ; 
x266: 34070 phone_number [ number x261^ ] 

x267: 34040 cart l_resul t_tuple [ person x264"^ ; address x265'' ; 
nil ; essn 999999999 ; proj_num 1 ; hours 45.2 ] 
x268: 34200 person[ fname x251^ ; mname x252^ ; Iname x253^ 
120926190 ; spouse 34180 "" ; sptr nil ] 

x269: 34210 addr [ street x256^ ; city x257^ ; state x258^ ; 
x27 0: 3 4220 phone_number [ number x2 61"^ ] 

x271: 34190 cartl_result_tuple [ person x268^ ; address x269"^ ; 
nil / essn 123456789- ; proj_num 2 ; hours 51.5 ] 
x272: 34350 person[ fname x251^ ; mname x252^ ; Iname x253^ 
120926190 ; spouse 34330 "" ; sptr nil ] 

x273: 34360 addr[ street x256^ ; city x257^ ; state x258^ ; 
x274: 34370 phone_number [ number x261^ ] 

x275: 34340 cart l_result_tuple [ person x212^ ; address x273^ ; 
nil ; essn 987654321 ; proj_num 30 ; hours 4.0 ] 



X276: 


10990 


"Jon" 






x277: 


11000 


"Lewis" 






x278 : 


11010 


"Spear" 






x279: 


30460 


"16 Sep 58" 






x280: 


34500 


person! fname x276^ 


■ ; mname x211^ 


; Iname x278^ 


123456789 ; 


spouse 34480 "" ; sptr nil ] 




x281: 


30480 


"3122 Apt B Sunset 


Strip" 




x282 : 


11030 


"Redondo Beach" 






x283 : 


11040 


"CA" 






x284: 


30490 


"99812" 






x285: 


34510 


addr[ street x2 81"^ 


; city x282^ ; 


state x283^^ ; 


x28 6 : 


30470 


" (301)322-2341" 




x287 : 


34520 


phone_number [ number x2 8 6"^ ] 




x288 : 


34490 


cart l_result_tuple [ 


person x2 80^^ ; 


address x285^ ; 



nil ; essn 550926190 ; proj_num 2 ; hours 10.0 ] 

x289: 34650 person[ fname x276^ ; mname x211'^ ; Iname x278^ 

123456789 ; spouse 34630 "" ; sptr nil ] 

x290: 34660 addr[ street x281^^ ; city x282^^ ; state x283^^ ; 
x291: 34670 phone_number [ number x286^ ] 

x292: 34640 cart l_resul t_tuple [ person x289"^ ; address x290^ ; 
nil ; essn 999999999 ; proj_num 1 ; hours 45.2 1 
x293 : 34800 person[ fname x276^ ; mname x211^ ; Iname x278"^ 
123456789 ; spouse 34780 "" ; sptr nil ] 

x294: 34810 addr[ street x281^ ; city x282^ ; state x283^^ ; 
x295: 3 48 20 phone_number [ number x2 86^^ 1 

x296: 34790 cart l_resul t_tuple [ person x293^ ; address x294^^ ; 
nil ; essn 123456789 ; proj_num 2 ; hours 51.5 ] 
x297: 34950 person[ fname x276^ ; mname x211'^ ; Iname x278^ 
123456789 ; spouse 34930 "" ; sptr nil ] 

x298; 34960 addr[ street x281^ ; city x282^^ ; state x283^ ; 
x299: 34970 phone_number [ number x286^ ] 

x300: 34940 cart l_result_tuple [ person x297^^ ; address x298^^ ; 

nil ; essn 987654321 ; proj_num 30 ; hours 4.0 ] 

x301: 30500 "Jon" 

x302: 30510 "K." 

x303: 13520 "Walter" 

x304: 30520 "24 Dec 61" 

x305: 35100 person[ fname x301'^ ; mname x302"^ ; Iname x303'^ 
991221234 ; spouse 35080 "" ; sptr nil ] 
x306: 30550 "3321 City St." 
x307: 30560 "Marina" 



zip x259^^ ] 

phone x262^ ; 
; bdate x254^ 
zip x259^ ] 
phone x266^ ; 
; bdate x254^ 
zip x259^^ ] 
phone x270^ ; 
; bdate x254^ 
zip x259^ ] 
phone x27 4^^ ; 



; bdate x279 



zip x284^ ] 

phone x287'^ ; 
; bdate x279^ 
zip x284^^ ) 
phone x291^ / 
; bdate x279^ 
zip x284^^ 1 
phone x295^^ ; 
; bdate x219' 
zip x284^^ 1 
phone x299^ ; 



; bdate x304 



widget 
; ssn 

widget 
; ssn 

widget 
; ssn 

widget 
; ssn 



widget 
; ssn 

widget 
; ssn 

widget 
; ssn 

widget 
; ssn 
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address x310^ ; phone x312^ ; widget 



zip x309^ ] 
phone x316^ 

; bdate x304^ 



; widget 



X308: 30570 "CA" 
x309: 30580 "93940" 

x310: 35110 addr[ street x306^^ ; city x307'^ ; state x308^^ ; zip x309^ 
x311: 30540 "(408)122-4253" 
x312: 3 5120 phone_nuraber [ number x311'" ] 
x313: 35090 cart l_result_tuple [ person x305^ 
nil ; essn 550926190 ; proj_num 2 ; hours 10.0 ] 

x314: 3 5250 person [ fname x301'^ ; mname x302'^ ; Iname x303'^ ; bdate x304^ 
991221234 ; spouse 35230 "" ; sptr nil ] 
x315: 35260 addr[ street x306^ ; city x307'^ ; 
x316: 3 5270 phone_number [ number x311'^ ] 
x317: 35240 cart l_result_tuple [ person x314'^ ; 
nil ; essn 999999999 ; proj_num 1 ; hours 45. 
x318; 35400 person[ fname x301"^ ; mname x302^ 

991221234 ; spouse 35380 "" ; sptr nil ] 
x319: 35410 addr [ street x306^ ; city x307'^ ; 
x320: 3 5420 phone_number [ number x311'^ ] 
x321: 3 53 90 cart l_resul t_t.uple [ person x318^ ; 
nil ; essn 12 3 4 56789 ; proj_num 2 ; hours 51. 
x322: 35550 person[ fname x301^ ; mname x302^ 

991221234 ; spouse 35530 "" ; sptr nil ] 

x323: 35560 addr [ street x306'^ ; city x307'" ; state x308'^ ; zip x309^^ ] 
x32 4: 3 5570 phone_number [ number x311"^ ] 

x325: 35540 cart l_result_tuple [ person x322^ ; address x323^ ; phone x324'^ ; widget 
nil ; essn 987654321 ; proj_num 30 ; hours 4.0 ] 
x326: 16700 person[ fname 16710 "" ; mname 16720 "" ; Iname 16730 
"" ; ssn 0 ; spouse 16750 "" ; sptr nil ] 

x327: 167 60 addr [ street 16770 "" ; city 16780 "" ; state 16790 
x328: 16810 phone_number [ number 16820 "" ] 
x329: 16690 cart l_result_tuple [ person x326^ ; address x327'^ ; phone x328'^ ; widget 
nil ; essn 0 ; proj_num 0 ; hours 0.0 ] 

x330: 16050 relation[ relat ion_name 16100 "Cart Resultl" ; at tribute_names 16150 
< xl62^ xl63^ xl64"^ xl65^ xl66‘^ xl67"^ xl68^ > ; at tribute_types 16320 < xl69^ xl70^ 
X171'' xl72^^ xl73"^ xl74^^ xl75"^ > ; tuples 31970 < xl88^^ xl92^ xl96"^ x200^^ x213^ 
X221'" x225^" X238'" x242'" x246^" x250'" x263"^ x267^" x271'" x275^ x288" x292^ x296'" 
x313^ x317^ x321^^ x325^^ > ; tuple_type x329^ ; key 16110 "ssn, essn, pro j_num" 



' ; Iname x303'^ 

state x308^^ ; 

address x315^^ ; 

.2 ] 

' ; Iname x303'^ 

state x308'^ ; 

address x319"^ ; 
.5 ] 

: Iname x303^ 



zip x309^" ] 

phone x320^ ; widget 

; bdate x304^^ ; ssn 



; bdate 16740 
zip 16800 "" ] 



x217 

x300 

] 

x331 

x332 

x333 



27930 name [ name 27970 "Hours Worked" ] 

27950 name[ name 27980 "Employee SSN" ] 

28000 name[ name 28040 "rational" ] 

x334: 28020 name [ name 28050 "integer" ] 

x335: 28090 pro ject l_resul t_tuple [ hours 20.4 
x336: 28150 pro ject l_result_tuple [ hours 3.2 ; 
x337: 28180 pro j ect l_resul t_tuple [ hours 67.25 
x338: 28060 pro ject l_result_tuple [ hours 0.0 ; 
x339: 27840 relation[ relat ion_name 28870 "project 1" 
x331'^ x332'" > ; attribute_types 27990 < x333^ x334^^ > ; 
x337"^ > ; tuple_type x338'^ ; key 27910 "essn" ] 
x340: 28300 proj_tuple[ essn 550926190 ; proj_num 2 ; 

x341: 28260 proj_tuple[ essn 0 ; proj_num 0 ; hours 0 

x342: 28190 relation [ relation_name 28250 "comp obj" 

; attribute_types 28220 < > ; tuples 28230 < x340^ > ; 



r essn 550926190 ) 
essn 123456789 ] 

; essn 987654321 ] 
essn 0 ] 

; attribute_names 27920 < 
tuples 27880 < x335" x336'" 

; hours 20.0 ] 

0.0 ] 

; attribute_names 28210 < > 
tuple_type x3 41'^ ; key 2 82 40 



x343: 28380 name [ name 28390 "" ] 

x344: 28420 addr [ street 28430 "" ; city 28440 "" ; state 28450 "" ; zip 28460 "" ] 
x345: 28480 person[ fname 28490 "" ; mname 28500 "" ; Iname 28510 "" ; bdate 28520 
"" ; ssn 0 ; spouse 28530 "" ; sptr nil ] 

x346: 28540 addr [ street 28550 "" ; city 28560 "" ; state 28570 "" ; zip 28580 "" ] 
x347: 28590 phone_number [ number 28600 "" ] 

x348: 28470 emp_tuple[ person x345"^ ; address x346^ ; phone x347^ ; widget nil ] 
x349: 28610 proj_tuple[ essn 0 ; proj_num 0 ; hours 0.0 ] 
x350: 28400 resul t_tuple ( values 28410 < x344^ x348'^ x349'^ > ] 
x351: 28620 resul t_tuple [ values 28630 < > ] 

x352: 28320 relation! relation_name 28370 "result test" ; att ribu te_names 28330 < 
x343^^ > ; att ribute_types 28350 < > ; tuples 28360 < x350^^ x351^^ > ; tuple^type 
nil ; key 28310 "" ] 
x353: 11120 "person -> ssn" 
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x354: 35630 relation [ relation_name 3564Q " lTEMP_rl . r4 " ; attribute_names 35650 < 
xl^ x2^ x3^ x4"^ > ; a ttribute_types x39^ ; tupleg 35660 < xl2'^ xl6^^ x20"^ x24'" x28'^ 
x32^^ xl28^ x51'^ > ; tuple^type x3 6^ ; key x35 3^ ] 

x355: 12510 database [ name 28640 "Relational Address DB" ; relations 12530 < x37"^ 
x56'" x73'" X113'" xl20^ xl33" xl38^ xl50" xl61'" x330" x339^ x342'" x352^ x354" > ] 
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APPENDIX E: MODIFIED R/OODBMS SCHEMA 



★ ★★★★★★★★★★Hr************************************************-*****-***-* 



★ ★★**** 



A Modified Relational/Object-Oriented Database Management System 

**★★★★★★****★****★**★******★**★★★**********★★*★*****■*:*★★★***★★*★*★***★**■**★****★ 



--Description : This file contains the IDL schema for the implementation of 
A Modified Relational/Object-Oriented Database Management 
System. Of the five primitive relational algebra operations 
(union, difference, project, select, and Cartesian product) , 
the project and Cartesian product operations have been modified 
from the original R/OODBMS implemented in IDB. 



structure relational root database is 



★*★★•*★*•**★★★★★■*★*★★★**■*★★**★*■*:★■*★*»■*■*• 



*★*★★★*★★*■•*■★★*•★★*•***★*•★***★*★*★★**★**★ 



database => 
database -> 
relation => 



relation -> 
relation -> 

name => 



name 

relations 
new_relation ( * } ; 



relation_name 

attribute_names 

attribute_types 

tuples 

tuple_type 

key 



: string, 

: seq of relation; 



string, 

seq of name, 

seq of name, 

seq of tuple, 

tuple, 

string; 



new_tuple ( * ) , 

check_union_compatabi lity ( relation, relation) => boolean; 



union ( * ) , 
projection { * ) , 
difference {*} , 
Cartesian_product ( * ) , 
selection ( * ) ; 



name 



string; 



tuple -> 



equal_to ( tuple, tuple, integer) 
less_than (tuple, tuple, integer) 
greater_than ( tuple, tuple, integer) 



=> boolean, 
=> boolean, 
=> boolean. 



initialize_tuple ( tuple) => tuple, 

insert_fields ( relation, relation) => relation. 



insert fields_b(reIation, relation, index_array) => relation, 

-- the b extension indicates modified methods used in this 
-- implementation. 



insert_tuples ( relation, relation, relation) => relation, 

insert_tuples_b(relation,relation,relation) => relation; 
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tuple 



emp_tuple I 
pi^oj_tuple 1 
cartl_resul t__tuple I 
pro jectl_resul t_tuple I 

result_tuple | 

nil ; 

-- in this implementation, result_tuple is the only tuple 
-- that needs to be defined for creating resultant relations 
-- in both the project and Cartesian product operations. Thus, 
-- cartl__result_tuple and pro ject l_result_tuple are not needed 
-- in this implementation. However, they have been left in so 
-- the reader could more easily compare this schema with that 
-- of the standard R/OODBMS schema. 



*•■*:★*■*•**★**★★** 



*•********•*★★********★*■*****★*★****★★★**★***★*★****★*★*★★★★★*★* 



for database . new_relation use browser_visible; 

for relation . new_tuple use browser_visible ; 

for relation .union use browser_visible ; 

for relation .Cartesian_product use browser_visible ; 

for relation .difference use browser_visible ; 

for relation .pro jection use browser_visible; 

for relation , selection use browser_visible; 



for database . relations use linked; 
for relation . tuples use linked; 



for database . idl_key use bind(database__key) ; 
for database . idl_print use bind(database_print ) ; 
for database . new_relation use bind {create_relation) ; 

for relation . idl__key use bind ( relation_key ) ; 
for relation . idl_print use bind ( relation_print ) ;• 
for relation . new__tuple use bind(create_tuple) ; 

for relation . check_union_compatability use bind(ck_union__compatabili ty ) ; 

for relation .union use bind (uni on_op) ; 

for relation .Cartesian_product use bind (car t_prod__op ) ; 

for relation .dif ference use bind (set__dif f_op) ; 

for relation .pro jection use bind (pro ject_op) ; 

for relation . selection use bind(select_op) ; 

for name.idl_key use bind (name_key ) ; 
for name . idl_print use bind(name_print) ; 

for tuple . equal_to use bind (equal_to ) ; 

for tuple . less_than use bind ( less_than) ; 

for tuple . greater_than use bind (greater__than) ; 

for tuple . initiali ze_tuple use bind ( initialize_tuple) ; 
for tuple . insert_fields use bind (insert_f ields) ; 
for tuple . insert__tuples use bind (insert_tuples) ; 

for tuple.insert_fields_b use bind(insert_fields_b); 
for tuple.insert~tuples[_b use bind(insert_tupl^_b); 



*★★***★****★*★**•****★★★***★*****•*★★**• 



emp_tuple 






emp_tuple => 



person : person, 

address : addr. 



186 





phone ; 


: phone_number, 




widget ; 


: idl_univ; 


person => 


f name 


string. 




mname 


string. 




Iname 


string. 




bdate 


string. 




ssn 


integer. 




spouse 


string. 




sptr 


person_nil ; 


person_nil : := 


person | nil; 


addr => 


street 


string. 




city 


string. 




state 


string. 




zip 


string; 


phone_number => 


number ; 


: string; 




**★■*■***★**1 


»:•*■★★**********★■ 



★ ★★★★★★★★★★*:*r***** 



for emp_tuple. idl_key use bind (einp_cuple_key ) ; 

for emp_tuple . idl_print use bind (emp_tuple_print ) ; 

for emp_tuple . equal_Co use bind (emp_equal_to) ; 

for emp_tuple . less_than use bind (einp_less_than) ; 

for einp_tuple.greater_than use bind (emp_greater_than) ; 

for emp_tuple . ini t ialize_tuple use bind ( initial i ze_einp_tuple) ; 

for emp_tuple.insert_fields_b use bind(insert_emp_fields_b); 

for person . idl_key use bind (person_key ) ; 
for person . idl_print use bind(person_print) ; 

for addr.idl_key use bind(addr_key) ; 
for addr . idl_print use bind (addr_print ) ; 

for phone_number . idljrint use bind (phone_number__print ) ; 

★ ★★★★★★★★★★★★★★★★★★*it**it******^****-*:p j-Q J ^Qp2^0*1lr******1t'*******************1>r*** 

proj_tuple => essn : integer, 

proj^num : integer, 
hours : rational; 



for proj_tuple , idl_key use bind (pro j_tuple_key ) ; 

for pro]_tuple . idl_print use bind (proj_tuple_print ) ; 

for pro]_tuple . equal_to use bind (pro j_equal_to) ; 

for proj_tuple . less_than use bind (proj_less_than) ; 

for pro]_tuple .greater_than use bind (pro j_greater_than) ; 

for proj_tuple . initialize_tuple use bind (initialize_proj_tuple) ; 

★ ★★*★★**★★★*****★★★★****★★★******00^-^^ result tuple* *****************^******** 



cartl_result_tuple => person 

address 

phone 

widget 

essn 

proj_num 

hours 



person, 

addr, 

phone_number , 
idl_univ, 
integer, 
integer, 
rational ; 






tcieicicieieieieicicie 



for cartl_resulc_tuple . idl_key use bind (cartl_resulc_tuple_key ) ; 



187 



for cartl_resul t_tuple . idl_print use bind (cart l_result_tuple_princ ) ; 
for cart l_result_tuple . ini tialize_tuple use 

bind ( initial ize_c art l_resul_tuple) 

for cartl_result_tuple . insert_tuples use bind ( insert_cartl_resul t_tuples ) ; 

proj ectl_resul t_tuple => hours : rational, 

essn : integer; 

*★★★**■*■**★•*★★*★★*★★★★★*★★**★★*★★★****★★**★***★★**★★****★★★**■***★**★★**★★***** 

for projectl_result_tuple. idl_key use bind (pro jectl_resul t_tuple_key) ; 
for proj ectl_resul t_tuple . idl_print use bind (pro jectl_result_tuple_print ) ; 
for projectl_resul t_tuple . initialize_tuple use 

bind ( initialize_pro jectl_resul_tuple) 
for projectl_result_tuple . insert_fields use bind (insert_proj ectl_resul t_f Ids ) 

*★***★**★***★*★***★*•*★***★★★***★*★**★**★★***★★★★★***★*★★★★★★*★*★**★*★★*★*★★■*★ 

result_tuple => values : seq of any; 

for result_tuple. values use linked; 



-- index_array is used by the project operation to hold a list of indexes 
-- to the attributes of a relation that^are to be projected. It cannot be 
-- reached from the database root and therefore can never be stored in the 
-- database by accident. It is purely set up as a data structure to allow 
-- the indexes to be passed as a parameter in the modified function 
project_op. 

index_array => indexes : seq of index; 

index => i : integer; 
for index_array.indexes use linked; 



★★***★★**★*★*★★**★★*★★**★★*★*****•*★★**★★*★*★★*★**★***★***★*★★*★★*★★*★★★★*★★★* 



end 









process relationalp is 

relational ::= relationala ; access ; 

end 
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APPENDIX F: MODIFIED PROJECT 



ic***ic**ific-k***ic*ieic*-k-k-k-kiir-ie-kie*ic-k-k-kieie-k-k-k-k-k-k-kieicicie*-k*-kic-kiir-k-kieicicie-k-k-k*ic******ic**->;**icicicirir 

Project_parse_action 

★ ***★★***••*•★*★★★★*★★•****★★**★★**•*•*★★******•****•**★★*★*★****★****★★★★★*★***★*★★★*★ 

static void Pro ject_parse_act ion (query) 
char* query; 

{ 

char *Rl_pt r, *char_ptr, *R2_ptr; 
integer size,i; 

boolean done = false , delimeterl = false; 



char_ptr = query; 

/* allocate room for parse of the project op parameters 
R1 will hold the relation being operated on, 

Attr_list the list of attr to be projected, and 
R2 the resultant relation */ 
size = strlen (query ) ; 

R1 = (char* ) calloc ( (size+1) , sizeof (char) ) ; /* R1 is global */ 

Attr_list = (char*) calloc ( (size+l ), sizeof (char) ) ; 

/* set pointers to move along R1 and R2 as characters are copied in one 
at a time. */ 

Rl_ptr = Rl; 

/* do the parse */ 
char_ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' = ' or ' project ' 
could not be found */ 
while (Idone && size > 0) 

{ 

if (*char_ptr != ' ') /* if not a space copy the char into R1 */ 

{ 

*Rl_ptr=*char_ptr; /*parameter relation*/ 

++char_ptr; 

-*-+Rl_pt r; 

--size; 

} 

else /* we may have hit a delimeter */ 

{ 

/* check to see if next char is a " p " - which is 
part of the delimeter " project "between the last 
two parameters */ 

if (strncmp (char_pt r, " project ",9) == 0) 

/* then it is project */ 

{ 

for (i =0; i < 9;++i) /* jump past the delimeter */ 

{ 

++char_ptr; 

- - s i z e ; 

} 

strcpy (Attr_list , char_ptr) ; 

/* copy list of attributes into Attr_list and now parse the 
list of attributes */ 
done=true ; 
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} 

else /* the space is part of the first parameter^ so put in R1 */ 

{ 

/* space is part of first relation name so keep it ! 
*Rl_ptr='^char_ptr ; 

++char_ptr; 

++Rl_ptr ; 

- - s i z e ; 

) 

} 

} 

if {size != 0) /* size only = 0 if union was not found in the query */ 
NULL; 
else 

idl_raise (IDL_ERROR, "There is an error in your query! Try Again."); 
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*★★***•**★******•*■★*★*★★***■■****•**■★**★**★★*★***★*■*■*★**•***■★**•*•»**• 



******** 



******* 



report_project_error 

************************************************* 



**************************** 



void report_pro ject_error ( f oundl , found2 , attr_found} 
boolean foundl, found2, attr_found; 



{ 



if ( 1 foundl ScSc !found2) 

{ 

idl_raise ( IDL_ERROR, 

"Neither of the two relations are in this database!"); 

} 

else 

{ 

if ( I attr_f ound) 

{ 

idl_raise ( IDL_ERROR, 

"All of the attributes in the attribute list \nare not in Rl! 

} 



if ( ! foundl ) 

{ 

idl_raise ( IDL_ERROR, 

"Rl is not in this database!"); 

} 

if ( ! found2 ) 

{ 

idl_raise (IDL_ERROR, 

"R2 is not in this database!"); 

} 



) ; 



} 



if (foundl ScSc 

{ 

idl_raise 



} 



f ound2 ) 

IDL_ERROR, 

"A SERIOUS ERROR HAS OCCURED ! ! ! 



I I 



Regroup. Try Again."); 
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project_op 

idl_routine void pro j ect_op (relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl ,ptr_Attr_list, ptr_result_rel , temp_relation ; 
relational_database database; 

relat ional_index_array array_index; /*beta project*/ 
relational_index attr_index; /*beta project*/ 
idl_trans_mode tmode; 
idl_univ root; 

string parameterl , attr_string; /* references to the parameter 

Rl,and attr list 
relations respectively */ 

idl_transaction tr; 

boolean f oundl , found2 , done, attr_f ound; 
boolean is_writable = false, duplicate = true; 

char *attr_ptr, *delimeter = /* delimeter between elements 

in attribute list */ 



string *attr_list [100 ] ; 

integer i=l , count , size, index, index_array [100] , ii=0; 

/* index array of size 100 allows a relation to have 100 attributes */ 
idl_linked_elem ( relational_tuple) resul t_tuple; 

tr = idl_get_trans (relation) ; 

tmode = i dl_trans_mode_de fault; 

root = idl_trans_get_root ( tr) ; 

database = idl_to (relational_database , root ) ; 

foundl = false; 

found2 = true;/* not needed for beta version, thus changed to true*/ 
done = false; 

is_wri table = ( idl_trans_wri te_count ( tr ) > 0); 

array_index = idl_new ( tr , relational_index_array ) ; /*creates the index array 

to be used in the beta 
version of this op*/ 

array _index->indexes = idl_empty_linked ( tr, relational_index) ; 



brw_input ( " Proj ect Query", 

"Please input the Project query (R1 project Attr_list) : " 
OL, OL, OL, false. 

Pro ject_parse_action) ; 



/* copy the C strings Rl, R2 and Attr_list into IDL strings */ 
parameterl = idl_copy_string ( tr , Rl ) ; /*relation being operated on*/ 
attr_string = idl_copy_string ( tr , Attr_l ist) ; 

/* parse tokens in attribute string */ 

if ((attr_ptr = strtok { attr_string, delimeter) ) == NULL) 

{ 

/* error, no token */ 
idl_raise ( IDL_ERROR, 

"You did not list any att ribute/f ield names inXnyour project query 
Try again, meathead!"); 

) 

else 

{ 

attr_list[0] = idl_new_string { tr, 80 ) ; 
attr_list(oj = idl_copy_string ( tr , attr_ptr) ; 

) 
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while ( (attrjtr = strtok (NULL, delimeter) ) != NULL) 

{ 

attr_list [i 1 = idl_new_st ring ( tr, 80} ; 
attr_list[i] = idl_copy_string ( tr , attr__ptr) ; 
i + + ; 

} 



/* search the database for the relation R1 */ 
idl_linked_f or ( relat ional_relation, database->relations , rel ) 

{ 

if (strcmp (rel->relation_name, parameterl ) == 0) 

/* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 

} 

} idl_end_for 

count = i; /* count is the number of tokens - 1 */ 

/* check each attr name in the attr list of the project operation to 
ensure that the field exists in the relation R1 */ 



f or ( i=0 ; i<count ; ++i ) 

{ 

attr_found = false; 
ii = 0; 

idl__array_for ( relational_name ,ptr_Rl->att ribute_names , aname) 

{ 

ii++; /* position in attribute list */ 

if (strcmp (aname->name, attr_list [i ] ) == 0) /* attr name in attr 

list is a field 
of R1 */ 

{ 

attr_found = true; 

attr_index = idl_new ( tr , relational_index) ; 
attr_index->i = ii; 
idl_insert_back (relational_index, 

array_index->indexes, attr_index) ; 

break; 

} 

} idl_end__for 

if ( ! attr_f ound) 

{ 

break; /* an attr in the project attr list is not 
in the relation R1 . Thus, the operation 
cannot be performed */ 

} 

} 

if (foundl ScSc attr_found) 

{ 

/* everything is ok, perform projection operation on relation R1 . 

Note, in this implementation, the resultant relation doesn't 
already exists in the database. */ 

ptr_result_rel = init_proj_result_rel(ptr_Rl,array_index}; 

ptr_result_rel=idl_vop (ptr_Rl->tuple__type, relat ional_tuple, insert_f ields_b, 

(ptr_Rl , ptr_result__rel , array__index) ) ; 

idl__insert_back ( relat ional_relation, database->relat ions , ptr_resul t_rel ) ; 

) 

else 

{ 
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reporC_projecC_error ( foundl , f ound2 , atCr_found) 
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★ ★*★★*★******★•*:★★*★******★**★**★**★***★*★★★*★*******★**★**********★★★★★*★★*★★**★ 



insert_fields_b 

★ ★★★★★★★★★★★★★★★★★★★★★★It******************************* 



★★★★★★★★★★★★★★★★★★★★★A 



idl_routine relat ional_relation insert_f ields_b { rel , resul t_rel , index_array } 
relational_relation rel, result_rel; 
re 1 a t i ona 1 _i ndex_a r ray i ndex_a r r ay ; 

{ 

return result_rel; 

} 
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***★■*•■*•★****•<?*★•*■**★★*★★**★★★**★***★*****★****★****★*★ 



★ ★★★★★★★★★★★★★★★★★★★★★★★★It 



insert_emp_fie!ds_b 

★★★★*★★★★★*★★★★★★★★★*★★*★★★★★★★★*★*★★★★★★★★★★★★*★★★★★★★★★★★ 



★★★★*★★★★★★★★★★★★★★★ 



idl_routine relational_relation ingert_emp_f ields_b {rel , result_rely index_array) 
relational_relation rel, result_rel; 
relational_index_array index_array ; 

{ 

idl_transaction tr = idl_get_trans { rel) ; 
relational_result_tuple new_cuple ; 

resul t_rel->tuples = idl_empty_linked { tr, relational_tuple ) ; 

idl_linked_for { relat ional_tuple, rel->tuples, rel__tuple) 

{ 

/* iterate through each tuple and for each tuple iterate through 

the index_array and use a case statement to reference objects for 
fields to be entered into the result relation */ 



new_tuple = idl_new {tr, relational_resul t_tuple) ; 
new_tuple->values = idl_empty_l inked ( tr, relational_any) ; 



idl_linked_for ( relational_index, index_array->indexes , index) 
{ 

switch (index->i) 

( 



function ! 



case 1 : 

idl_insert_back (relational_any , new_tuple->values, rel_tuple->person) ; 

break; 
case 2: 

idl_insert_back (relational_any , new_tuple->values, rel_tuple->address ) ; 
break; 
case 3 : 

idl_insert_back (relational_any , new_tuple->values, rel_tuple->phone) ; 
break; 
case 4 : 

/* widget */ 
break; 
default : 

idl_raise (IDL_ERROR, 

"There is a problem in the employee insert field beta 



break; 



} idl_end_for 

idl_insert_back (relational_tuple, result_rel ->tuples , new_tuple) ; 
) idl_end_for 
return result_rel; 

) 
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******************************************************************************* 



initj)roj_result_rel 

***************************************************************** 



************* 



relational_relation ini t_proj_result_rel (ptr_Rl , index_array ) 
relational_relation ptr_Rl; 
relational_index_array index_array ; 

{ 

relat:ional_relation resul t_relation; 

static integer result_rel_num = 0; 

idl_t ransaction tr; 

string empty , re sult_rel_name; 

char result_name [ 80 ] ; 

integer degree = 0,i; 

tr = idl_get_trans (ptr_Rl ) ; 

i=0; 

idl_linked_for (relational_index, index_array->indexes , index) 

{ 

i+ + ; 

} idl_end_for 
degree = i; 

result_relation = idl_new ( t r, relational_relation) ; /* must still assign 

legal values */ 



/* set up a unique name for resultant relation */ 
sprint f (result_name, " %ldRESULT_%c%c^' , 

+ + resul t__re l_num , 
ptr_Rl->relation_name [0 ] , 
ptr_Rl->relation_name [ 1 ] ) ; 
resul t_rel_name = idl_copy_st ring ( tr, resul t_name) ; 

result_relation->relation_name = resul t_rel_name; 

resul t_relation->attribute_names = idl_new_array ( tr, relational^name , degree) ; 
result_relation->attribute_types = idl_new_array ( tr, relational_name , degree) ; 

/* assign default values for attribute names to be the same as those in 
R1 relation */ 
i=0; 

idl_l inked_f or ( relational_index, index_array->indexes , index) 

{ 

resul t_relation->attribute_names ( i ] =ptr_Rl->attribute_names [ ( index->i ) -1 ] 
result_relation->attribute_types [ i] =ptr_Rl->attribute_types [ ( index->i ) -1] 
i + + ; 

) idl_end_for 

result_relation->tuples = idl_empty_linked ( tr , relat ional_tuple) ; 

/* assign a default tuple type that is the same as the first relations */ 
result_relation->tuple_type = idl_to ( relational_tuple, 

idl_new ( tr , relat ional_result_tuple) ) ; 

/* default key is the key of relation R1 */ 
resul t_relation->key = ptr__Rl->key ; 

return result_relation; 
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APPENDIX G: MODIFIED CARTESIAN PRODUCT 



★★★★★★★★★★★★★It****************************************************** 



* * •* * 



Cartesian_parse_action 

★ ★★★★★★★★★★★★★★★★★★★★★★★★★Hr************************************************ 



Static void Cartesian_parse_action (query ) 
char* query; 

{ 

char *Rl_ptr, *char_ptr; 
integer size,i; 

boolean done = false, delimeterl = false; 



char_ptr = query; 

/* allocate room for parse of the Cartesian product op parameters 
R1 will hold the first parameter and R2 the second */ 
size = strlen (query ) ; 

R1 = (char* ) calloc ( (size+1 ), sizeof (char) ) ; 

R2 = (char* ) calloc ( (size+1 ), sizeof (char) ) ; 

/* set pointer to move along R1 as characters are copied in one 
at a time. */ 

Rl_ptr = Rl; 

/* do the parse */ 
char_ptr = query; 

/* note: if size gets decremented all the way to zero, then there is a 
problem with the query because the delimeter ' X ' could not be 
found */ 

while (!done && size > 0) 

{ 

if (*char_ptr != ^ ') /* if not a space copy the char into R3 */ 

{ 

*Rl_ptr=*char_ptr ; 

++char_pt r; 

++Rl_pt r ; 

--size; 

} 

else /* we may have hit the a delimeter */ 

{ 

/* check to see if next char is a " X " - which separates the 
two operands of the operation */ 

if (strncmp (char_ptr, " X ",3) == 0) /* then it is X sentinal */ 

{ 

for (i =0; i < 3;++i) /* jump past the delimeter */ 

{ 

++char_ptr; 

- - s i z e ; 

} 

strcpy (R2 , char_ptr) ; /* copy second parameter into R2 */ 
done=true; 

} 

else /* the space is part of the first parameter, so put in Rl */ 

{ 

/* space is part of first relation name so keep it */ 
*Rl_ptr=*char_ptr ; 

++char_pt r; 
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++Rl_ptr; 

--size; 
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****★**•*•**★***★**★**★*★★*★•*■★***★•*■**■*■******★*•**★★★****★★*****■***★*★*■*■★**★★★■*■*★★★ 



report_Cart_product_error 



:*************************★*****★**********★*********************************** 



void report_Cart_product_error { f oundl , f ound2 , founds ) 
boolean f oundl , founds , founds ; 

( 

if {! f oundl ScSc ! founds) 



{ 



idl_rai se ( I DL_ERROR , 

"Neither of the two relations are in this database!"); 



else 

{ 



if (I f oundl ) 



( 



} 



idl_raise { IDL_ERROR/ 

"R1 is not in this database!"); 



if ( ! founds ) 



{ 



) 



idl_raise(IDL_ERROR, 

"RS is not in this database!"); 



if ( ! founds ) 



{ 



) 



idl_raise { IDL_ERROR , 

"RS is not in this database!"); 



if (f oundl ScSc founds && founds ] 



{ 



idl_raise (IDL_ERROR, 

"A SERIOUS ERROR HAS OCCURED !!!!!! Regroup. Try Again."); 
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*★**★***★*******■****★***★*•*•★*******★***•******■*■*■****■************•**•★*****•****★ 

cartj)rod_op 

*****★***********★***■*■**********'*■**■*■****■*■****'*■******■**■*•*★**■**■*■*■★*******★**'*■* 

idl_routine void cart_prod_op (relation) 
relational_relation relation; 

{ 

relational_relation ptr_Rl , pt r_R2 , resutl_rel , temp_relation; 
relational_database database; 
idl_trans_mode tmode; 
idl_univ root; 

string parameterl , parameter2 , result_rel ; /* references to the parameters 

Rl, R2 and R3 respectively */ 

idl_transaction tr; 
boolean f oundl , f ound2 , f ound3 ; 

boolean is_writable = false, duplicate = true; 

tr = idl_get_trans ( relation) ; 

tmode = idl_trans_mode_defaul t ; 

root = idl_trans_get_root ( tr) ; 

database = idl_to (relational_database, root ) ; 

foundl = false; 

found2 = false; 

founds = true; /* beta version doesn't use a predefined result rel */ 
is_writable = ( idl_trans_write_count ( tr ) > 0) ; 

brw_input ( "Cartesion Product Query", 

"Please input the Cartesian product query (R1 X R2) : ", 

OL, OL, OL, false, 

Cartesian_parse_action) ; 

/* copy the C strings R1 and R2 into IDL strings */ 
parameterl = idl_copy_s tring ( tr , R1 ) ; 
parameters = idl_copy_string ( t r, R2 ) ; 

/* don't do anything if the resultant relation is one of the two operands. 
However, the resultant relation can be one that exists in the data. 

In this case, the specified resultant relation will be over written. */ 

/* search the database for the two relations: Rl, and R2 */ 
idl_l inked_for ( relational_relation, database->relations, rel ) 

{ 

if (strcmp ( rel ->relation_name, parameterl ) == 0) 

/* found relation 1 */ 

{ 

ptr_Rl = rel; /* point at relation 1 */ 
foundl = true; 

) 



if (strcmp 
/* found 
{ 

ptr_R2 

founds 



( rel->relation_name, parameters ) 
relation 2 */ 

= rel; 

- true; 



== 0 ) 



} idl_end_for 



if (foundl ScSc founds) 

{ 

/* perform concatenation of tuples for Cartesian product. 

Note, in this implementation, the resultant relation does not 
already exists in the database. */ 

result_rel = ini t_Cart_result_rel (ptr_Rl , ptr_R2 ) ; 
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result_rel = idl_vop ( result_rel->tuple_type , relat ional_tuple, inserc_tuples_b, 

(ptr_Rl , ptr_R2 , result_rel ) ) ; 

idl_insert_baclc (relational_relation, database->relations , resul t_rel ) ; 

} 

else 

{ 

report_Cart_product_error ( f oundl , f ound2 , founds ) ; 

} 

} 
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***★**★★★★★***★***★** *** 



★ ★★Hr************************************************** 



init_Cart_result_rei 



★************************************* 



***************************************** 



* * 



relational^relation ini t_Cart_resul t_rel (ptr_Rl , ptr_R2 ) 
relational_relation ptr_Rl , ptr_R2 ; 

{ 

relational_relation resul t_relation; 
static integer resul t_rel_num = 0; 
idl_t ransaction tr; 
string resul t_rel_name; 
char result_name [ 80 ] ; 

integer degreel = 0,degree2 = 0 , resul t_degree, i ; 
tr = idl_get_trans {ptr_Rl ) ; 

degreel = idl_array_size {pt r_Rl ->attribute_names) ; 
degree2 = idl_array_size (ptr_R2->attribute_names) ; 
resul t_degree = degreel + degree2; 

resul t_relation = idl_new ( tr , relational_relat j on) ; /* must still assign 

legal values */ 



/* set up a unique name for resultant relation */ 

sprintf {resul t_name, " %ldRESULT_%c%c . %c%c" , 

+ + resu 1 t_re l_num , 
ptr_Rl->relation_name [0 ] , 
ptr_Rl->relation_name [1 ] , 
ptr_R2->relation_name [0 ] , 
ptr_R2->relation_name [1 ] ) ; 

resul t_rel_name = idl_copy_string(tr,result_name); 

resul t_relation->relation_name = result_rel_name; 

resul t_relation->attribute_names = idl_new_array ( tr , relational_name, 

resul t_degree) ; 

resul t_relation->attribute_types = idl_new_array ( tr , relational_name , 

resul t_degree) ; 

/* assign default values for attribute names to be the same as those in 
R1 and R2 */ 

for ( i=0; i<degreel; ++i) 

( 

resul t_relation->attribute__names [ i ] = ptr_Rl->attribute_names [i ] ; 
resul t_relation->attribute_types [i] = ptr_Rl->attribute_types [i ] ; 



for ( i=0; i<degree2; ++i) 

( 

resul t_relation->attribute_names [degreel+i ] = ptr_R2->att ribute_names [i ] ; 
resul t_relation->attribute_types [degreel+i ] = ptr_R2->att ribute_types [i ] ; 



resul t_relation->tuples = idl_empty_l inked ( tr, relational_tuple) ; 

/* assign a default tuple type result tuple */ 
resul t_relation->tuple_type = idl_to ( relational_tuple, 

idl_new ( tr , relational_result_tuple) ) ; 

/* default key is the key of relation R1 */ 
resul t_relation->key = ptr_Rl->key; 

return result_relation; 

) 
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★ ★*■**•**■*■**■***************•*■***•***•**■***■****■*★*****■*•*****■**★**************■****•***■** 



insert_tuples_b 

**************★**************•*■*•*:***■*■***■*'********★****»★**■*******■**■*•**•** 



*•**•*:■*•**• 



static relational_relation insert__Cuples_b ( rl , r2 , result_rel ) 
relational_relation rl , r2 , result_rel ; 

{ 

relational_resul t_tuple new_tuple ; 
relational_tuple rell,rel2; 
idl_transaction tr = idl_get_trans ( rl ) ; 

/* get rid of any tuples that may be in the resultant relation structure 
prior to insert the new result */ 

resul t_rel->tuples = idl_empty_linked ( t r, relational_tuple ) ; 

idl_linked_for (relational_tuple, rl->tuples, rl_tuple) 

{ 

idl_l inked_for (relational_tuple, r2->tuples , r2_tuple) 

{ 

/* send message to get a new tuple created with valid default 
values. */ 

new_tuple = idl_new ( tr , relational_resul t_tuple) ; 
new_tuple->values = idl_empty_l inked ( tr, relational_any) ; 

idl_insert_back ( relational_any , new_tuple->values, rl_tuple) ; 
idl_insert_back (relational_any , new_tuple->values, r2_tuple) ; 

idl_insert_back ( relat ional_tuple, result_rel->tuples, new_tuple) ; 

} idl_end_for 
} idl_end_for 

return result_rel; 

) 
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